پس از چند سال کار در یک استارت‌آپ بزرگ‌تر، و یادگیری چند درس سخت در طول مسیر، تصمیم گرفتم اصولی را که فکر می‌کنم جهانی هستند به اشتراک بگذارم. مطمئنم استثناهایی وجود خواهد داشت، مانند استارت‌آپ‌هایی با باندهای تقریباً نامحدود که توسط یک خیر سخاوتمند تأمین مالی می‌شوند، اما برای بقیه ما فقط زمان زیادی داریم تا مجبور شویم آن را ترک کنیم.
دو هدف بر تمام اصول مشترک من تأثیر می گذارد.
1) دستیابی به سرعت.
2) محرک رشد.
من با اصول کلی شروع می کنم و در ادامه با اصول فنی تر شروع می کنم.
تمرکز
حتی اگر ما یک استارت‌آپ تک نفره باشیم، هدف منحصر به فرد ما می‌تواند از بین برود و فراموش شود، زیرا سرمان را پایین کار می‌گذاریم. تصور کنید که حفظ تمرکز با یک تیم چند نفره چقدر دشوارتر است.
اگر هدف ما این است که 100 مشتری اول، به عنوان توسعه دهنده، ممکن است به سندرم چشم براق مبتلا شویم. زمانی که به 100 مشتری رسیدیم، ممکن است نگرانی در مورد مقیاس‌بندی را آغاز کنیم، زمانی که باید به تکرار ویژگی‌ها ادامه دهیم.
چه تیمی تک نفره باشیم و چه چند نفره، باید به یک سمت حرکت کنیم. اگر دایره ای بچرخیم نمی توانیم پیشرفت کنیم. بنابراین باید به طور منظم یادآوری شود که تمرکز بر روی ماه، هفته، روز و حتی ساعت چیست. خیلی آسان است که هدفمان را فراموش کنیم و در مسیرهای جانبی قرار بگیریم.
و باید روی چه چیزهایی تمرکز کنیم؟ بستگی به این دارد که کجا باشیم:
- به دست آوردن اولین مشتری به عنوان مثال، آیا ما نیاز داریم که اولین ویژگی را از در خارج کنیم؟ چقدر سریع می توانیم تکرار کنیم؟
- در حال رشد به ن مشتریان به عنوان مثال آیا ما به ویژگی های بیشتری نیاز داریم؟ چقدر سریع می توانیم موارد بیشتری را آزاد کنیم؟
- جلوگیری از ریزش به عنوان مثال آیا ما نیاز به رفع اشکال و بهبود پایداری داریم؟
ذات گرایی
نقدی برای کتاب، Essentialism نوشته گرگ مک‌کئون، می‌گوید: «اساسیالیسم این نیست که کارهای بیشتری را در زمان کمتر انجام دهیم، بلکه فقط انجام کارهای درست است.» این چه تفاوتی با تمرکز دارد؟ من معتقدم که ابتدا باید تمرکز را تعیین کنیم، سپس می توانیم مطمئن شویم که تمام اقدامات ما در جهت هدف ما کار می کنند.
نمودار گرگ مک کئون مفهوم او را کاملا توضیح می دهد. وقتی تمام انرژی خود را صرف حرکت در یک جهت می کنیم، این اتفاق می افتد. ما فراتر از تلاش برای گسترش توجه خود در بسیاری از چیزها خواهیم بود.
به چه معنا است برای ما؟
اگر می‌خواهیم به تناسب محصول با بازار برسیم، احتمالاً ویژگی‌های مختلفی را امتحان می‌کنیم که با مشتریان طنین‌انداز می‌شوند و به سرعت چیزها را می‌سازیم.
- آیا باید نگران زیرساخت ها باشیم؟
- آیا حتی باید نگران پوسته پوسته شدن باشیم؟
- آیا باید نگران تمیزترین و قابل نگهداری ترین کد باشیم؟
اگر انجام آن کارها سرعت ما را کاهش دهد و حتی نتوانیم یک مشتری جذب کنیم زیرا وقت ما صرف نگرانی در مورد چیزهایی می شود که تمرکز اصلی ما نیستند، در این صورت زمان و منابع را تلف می کنیم. ما در حال حل مشکلی هستیم که نداریم و ممکن است هرگز نداشته باشیم.
کوچک رها کنید، اغلب رها کنید
از دیدگاه یک توسعه دهنده، نسخه های بزرگ کاملاً وحشتناک هستند.
بسیاری از کدهایی که وارد تولید می‌شوند، می‌توانند همه نوع اشتباه داشته باشند، نه لزوما در ابتدا، بلکه در ساعات و روزهای آینده. داشتن تعداد زیادی نسخه کوچک خطر معرفی باگ ها را کاهش می دهد. اما دیدگاه دیگری وجود دارد.
وقتی می‌خواهیم پذیرنده‌های اولیه داشته باشیم، حتی داشتن یک قطعه کوچک از یک محصول در چند ساعت یا چند روز بهتر از داشتن محصول نهایی فوق‌العاده ماموت در ماه‌ها یا سال‌ها است! اگر بتوانیم محصول را به دست کسی برسانیم و بازخورد دریافت کنیم، از نقطه نظر فنی و از دیدگاه محصول به سرعت یاد خواهیم گرفت. با این بازخورد سریع، می‌توانیم تصمیم بگیریم که آیا باید در آن مسیر به سمت این هدف بزرگ قدم برداریم، یا باید در زمانی که جلوتر هستیم، حرکت کنیم یا آن را رها کنیم.
زمان را برای مشکلات توسعه دهندگان تلف نکنید
من به استخدام ابزارهایی مانند استخدام افراد اعتقاد دارم.
اگر ما یک مهندس نرم‌افزار در تیم خود داریم، آنها برای ساخت محصولات منحصر به فرد برای ما حاضرند. بنابراین از اجازه دادن به مهندسان نرم افزار ما برای استفاده از ابزارها، چه پولی و چه رایگان، نترسید. استفاده از این ابزارها تقریباً مانند استخدام شخصی است که آنها را ساخته است یا به آنها پول می دهید اما با هزینه های بسیار کمتر.
اما ممکن است فکر کنید، چرا یک توسعه دهنده باید از ابزارهایی استفاده کند در حالی که باید بتواند آنها را بسازد؟
به عنوان مثال، افراد بسیار کمی به فکر ساختن درگاه پرداخت خود به طور مستقیم با بانک ها هستند، مگر اینکه تمرکز ما بر تبدیل شدن به Stripe یا Paddle بعدی باشد!
بنابراین، به‌عنوان مثال، به‌جای اینکه به توسعه‌دهنده ما اجازه دهیم یک ادغام درگاه پرداخت را از ابتدا برای جمع‌آوری پرداخت‌ها بسازد، که ظاهراً Stripe 6 ماه طول کشید، می‌توانیم با استفاده از خدمات پرداختی که این کار را برای ما انجام می‌دهند، یک رابط کاربری پرداخت زیبا در یک روز یا کمتر راه‌اندازی کنیم. تفاوت؟
هزینه با استفاده از پرداخت شرکت SaaS = هزینه تراکنش + 1 روز توسعه دهنده
هزینه استفاده از توسعه دهنده خود ما = 120 روز توسعه دهنده + تن زمان نگهداری!
هنگامی که به مقیاسی رسیدیم که در حال حاضر بهینه سازی هزینه ها را انجام می دهیم، می توانیم نگران همه این چیزهای دیگر باشیم. ما واقعاً ممکن است راه ارزان‌تری برای مدیریت زیرساخت‌ها داشته باشیم، مانند DHH وقتی که AWS را ترک کرد. اما در این بین، ما به‌عنوان توسعه‌دهندگان باید مکرراً بپرسیم که آیا من روی یک مشکل توسعه‌دهنده کار می‌کنم و آیا ابزاری وجود دارد که بتوانم از آن استفاده کنم تا بتوانم روی مشکلات تجاری کار کنم؟
اساساً، حداقل، نه پیش از موعد، چرخ را دوباره اختراع نکنید. چیزهایی بسازید که مختص کسب و کار هستند.
ابزارهایی را استخدام کنید تا از اتلاف وقت در تعمیر و نگهداری جلوگیری کنید
برخی افراد می گویند که توسعه دهندگان واقعی احراز هویت خود را ارائه می کنند. اما اجازه دهید احراز هویت را به عنوان مثال در نظر بگیریم. این فقط یک جدول کاربر نیست. این ایمیل ها را مدیریت می کند. این در حال رسیدگی به بازگرداندن ایمیل است. اگر واقعاً بخواهیم از اطلاعات مشتری محافظت کنیم، پیامک و 2FA است. گذرواژه‌ها و اسرار مشتری را به درستی مدیریت می‌کند.
از طرف دیگر، می‌توانیم از ابزارهای منبع باز استفاده کنیم یا ابزارهای شخص ثالث را از شرکت‌ها استخدام کنیم. واقعاً، این شرکت‌ها می‌توانند ده‌ها و نه صدها توسعه‌دهنده داشته باشند که روی راه‌حلی که ارائه می‌کنند کار می‌کنند. وقتی از این ابزارها استفاده می کنیم، این افراد را استخدام می کنیم! ما متخصص آنها را استخدام می کنیم.
به عنوان مثال، با Okta یا Auth0، آنها با بهترین شیوه های امنیتی همگام هستند و محصولات خود را همیشه بهبود می بخشند. اگر یک وصله امنیتی وجود داشته باشد که آنها باید اعمال کنند، به احتمال زیاد، بدون اینکه ما در مورد آن بدانیم، آن تغییرات ارائه می شود و برای ما کار می کند. مگر اینکه ما سعی می کنیم ارائه دهنده بعدی احراز هویت باشیم، چرا از این شرکت ها و ابزارها استفاده نکنیم؟
در مورد زیرساخت نیز همینطور است، که برای من سخت است زیرا واقعاً سرورهایم را دوست دارم. راه اندازی Let's Encrypt، نوشتن یک GitHub Action و داشتن CI/CD کامل مشکلی ندارد. حداکثر یک یا دو ساعت طول می کشد اگر از ابتدا این کار را انجام دهم. اما باید اعتراف کنم که در مورد حملات DDoS و مدیریت آن چطور؟ در مورد وصله های سرور، که در برخی مواقع مورد نیاز خواهند بود، چطور؟ در مورد مقیاس زیر برای برآوردن نیازهای مشتری چطور؟ اینها همه چیزهایی هستند که من باید با تصمیم گیری برای حفظ آن چیز نگران باشم.
از طرف دیگر، من فقط می‌توانم از زیرساخت‌ها به‌عنوان یک سرویس استفاده کنم که همه این کارها را برای من انجام می‌دهد، و برخی از آنها دارای سطوح رایگان هستند که فقط کافی است ما را تا زمانی که شروع به جذب کاربران کافی برای نگرانی در مورد نحوه برخورد با هزینه‌ها کنیم، کافی است. مقیاس
بنابراین ما یک انتخاب داریم. ما می‌توانیم توسعه‌دهنده‌ای داشته باشیم که هفته‌ها، شاید ماه‌ها در سال، نگران این چیزهایی باشد که مشتریان ما ما را برای آن استخدام نکرده‌اند. ما ممکن است اینجا یا آنجا کمک هزینه کنیم، اما واقعاً باید تصمیم بگیریم که آیا می توانیم هزینه کنیم یا نه.
نظارت به عنوان QA
من با برخی از بهترین مهندسان QA کار کرده ام، و آنها به معنای واقعی کلمه از ورود صدها اشکال، اگر نه هزاران، جلوگیری کرده اند. با این حال، اگر ما در حال شروع کار هستیم و هنوز مشتری کافی نداریم، استخدام یک مهندس QA عالی تمرکز ما نخواهد بود. پس در عوض چه کنیم؟
استفاده از چیزی مانند Bugsnag، یک پلتفرم مشاهده‌پذیر که اشکالات را بررسی می‌کند و مشکلات تجربه کاربران در تولید را بررسی می‌کند، به این معنی است که ما از نظارت خود به عنوان QA استفاده می‌کنیم. به محض بروز خطای کنترل نشده، Bugsnag به ما هشدار می دهد و خلاصه ای از مشکلات را به ما ارائه می دهد. این به معنای عدم آزمایش به عنوان یک توسعه دهنده نیست، زیرا حتی برای یک پروژه نسبتا ساده، من از TDD برای نوشتن منطق اصلی استفاده کردم. با این حال، این بدان معناست که زمان زیادی را صرف تلاش برای تضمین کیفیت محصول خود نکنید و سرعت انتشار را کاهش دهید. علاوه بر این، یک مهندس QA احتمالاً به هر حال کار بهتری برای آزمایش کد ما انجام می دهد، به خصوص با چشمانی تازه.
اصول خود را بنویسید
اگر ما مهندس موسس یا CTO هستیم، باید اصول خود را بنویسیم تا وقتی توسعه دهندگان جدید را سوار می کنیم، مجبور نباشند برای تصمیم گیری از ما میلیون ها سوال بپرسند. آنها این استقلال را خواهند داشت که فقط با کارها پیش بروند.
این باعث صرفه جویی در وقت ما می شود، زیرا ما اصول اصلی خود را با تیم خود به اشتراک می گذاریم، و همچنین باعث صرفه جویی در وقت آنها می شود. اگر هیچ کس دیگری با ما کار نمی کند، ممکن است اهمیت دادن به آن در اولویت نباشد، اما هیچ چیز مانع از داشتن یک لیست سریع از 3 یا 4 چیز در یک جمله یا کمتر نیست. مثلا:
- از یک ابزار شخص ثالث با لایه رایگان > منبع باز > خود استفاده کنید.
- از ابزارهای موجود استفاده کنید مگر اینکه وجود نداشته باشد.
- از یکپارچه مدولار بر روی سرویس جداگانه استفاده کنید.
- قبل از اینکه نگران پوسته پوسته شدن افقی باشید، مقیاس عمودی را تنظیم کنید.
نقشه راه شفاف داشته باشید
نقشه راه نباید فقط برای تیم فناوری باشد، بلکه برای کل شرکت باشد. همه باید بتوانند نگاهی به آن بیندازند و بدانند که ما در حال حاضر روی چه چیزی کار می کنیم، چه کاری انجام شده است و چه چیزی در آینده خواهد آمد.
چرا؟ دو چیز:
- این به تیم ما تمرکز می کند. اگر کاری در نقشه راه در حال انجام است، اما ما روی چیزهای دیگری کار می کنیم، باید از خود بپرسیم که چرا؟
- اگر با مشتریان فعلی و بالقوه صحبت کنیم، مکالمات را بسیار آسان‌تر می‌کند، زیرا می‌دانیم چه چیزی در راه است.
حالا اینکه آیا ما این نقشه راه را با دنیای بیرون به اشتراک می گذاریم، به ما بستگی دارد، اما برخی از شرکت ها این کار را با تاثیر بسیار خوبی انجام داده اند! Supermetrics را در نظر بگیرید. مشتریان آنها نقشه راه خود را می‌دانند، چه ادغام‌هایی در حال ساخت هستند و حتی می‌توانند پیشنهادهایی برای ابزارهایی برای ادغام با آنها ارائه دهند.
آنچه را که می توانیم در آن مولد باشیم انتخاب کنیم
من عاشق استفاده از ابزارهای جدید هستم. من بی صبرانه منتظر یادگیری زیگ و رست هستم. من می خواهم با Go بر روی محصولی با مشتریان کار کنم، نه فقط پروژه های شخصی. من می دانم که همه به وضوح از Next.js استفاده می کنند. پس از سال‌ها کار با Vue.js، با دانستن اینکه React هنوز خشم است، احساس می‌کنم باید دوباره آن را انتخاب کنم، اما آیا واقعاً نیاز به ساخت یک برنامه تک صفحه‌ای داریم؟ آیا می‌توانیم از یک سرور Go یا Node.js با مقداری HTMX و Alpine.js استفاده کنیم؟ اگر مسیر React را پایین بیاوریم، باید یک API ایجاد کنیم. آیا به API نیاز داریم؟ سپس ما به اعتبار سنجی روی کلاینت و باطن نیاز داریم. آیا ما فقط می توانیم اعتبار سنجی در باطن داشته باشیم؟ آیا به دو گیت مجزا نیاز داریم؟[Hub|Lab]/ مخازن بیت باکت؟ آیا ما به داکر نیاز داریم؟ یعنی ما واقعا؟ حتی ممکن است بپرسیم که آیا ما حتی به سرور نیاز داریم؟ آیا می‌توانیم چیزی مانند Firebase و فقط یک برنامه ثابت در Netlify یا Vercel یا چیز دیگری داشته باشیم؟ آیا می توانیم فقط از توابع با توابع به عنوان یک سرویس استفاده کنیم؟
بسته به مهارت ها و شایستگی های اصلی ما، شروع با آنچه می دانیم به این معنی است که می توانیم سریعاً بهره وری داشته باشیم. اما گاهی اوقات، انتخاب چارچوبی که بیشتر کارها را برای ما انجام می دهد، به خصوص اگر بدانیم که به آن نیاز خواهیم داشت، زندگی ما را بسیار ساده تر می کند، اگر مایلیم زمان کمی برای یادگیری آن از قبل اختصاص دهیم. . من این کار را با HTMX مانند دیوید گیوت انجام دادم. اما اگر یک روز فرصت داریم تا آن ویژگی یا بخشی از آن ویژگی را منتشر کنیم و باید از آنچه می‌دانیم استفاده کنیم، این احتمالاً ساده‌ترین و پربازده‌ترین کاری است که می‌توانیم انجام دهیم، حتی اگر کارآمدترین نباشد.
حالا اگر تمام وقت دنیا را داشته باشیم، می‌توانیم موضوع را به هر اندازه که دوست داریم پیچیده کنیم: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition.
کاری کن که کار کند، درستش کن، شاید سریع انجامش بده
ضرب المثلی وجود دارد که می گوید آینده نگری 20/20 است. ما بیشتر در مورد پروژه در پایان می دانیم تا در ابتدا. و شاید بسیاری از ما کارهای زیادی داشته باشیم که اگر می‌توانستیم دوباره روی یک پروژه کار کنیم، متفاوت انجام می‌دادیم. بنابراین ساختن یک چیز به سرعت دقیقاً همین را به ما می دهد.
به جای تلاش برای کدنویسی صحیح یک ویژگی در بار اول، مگر اینکه دقیقاً بدانیم در حال انجام چه کاری هستیم، آن را بسازید، سپس آن را درست کنید. اگر سعی کنیم چیزی را به درستی از قبل بسازیم، نه تنها خطر ساخت چیزی را داریم که ممکن است مشتری از آن استفاده نکند، بلکه در خطر اتلاف وقت برای ساخت آن هستیم، زیرا به هر حال بار اول اشتباه می کنیم و زمان بیشتری را برای انجام آن صرف می کنیم.
مراسم و فرآیندها را فراموش کنید
«فرایندهای چابک» خشم هستند، اما یکی از اصول بنیادین بنیانگذاران مانیفست چابک، بهینه سازی برای «افراد و تعاملات بر روی فرآیندها و ابزارها» است.
دریافته‌ام که بهتر است فواصل زمانی منظمی را در نظر بگیریم تا مشخص کنیم چه چیزی در کانون توجه است، سپس دو برابر شده و به ساختن و انجام هر فعالیتی که برای رشد کسب‌وکار نیاز است بازگردیم. بنابراین من نگران دوی سرعت، استندآپ، مراسم و نکات داستانی نیستم. اگر آنها به ما کمک کنند تا نرم‌افزار را سریعتر بسازیم، اما به احتمال زیاد، ما نیازی به انجام هیچ‌یک از این کارها نداریم، اما در عوض، می‌توانیم کارهایی را انجام دهیم که برای ما مفید است.
فشار به تولید
مگر اینکه برای ما حیاتی باشد که این کار را نکنیم، مستقیماً به تولید فشار بیاوریم. اگر مجبور به استقرار دستی باشیم، متوجه می‌شویم که همیشه سعی می‌کنیم از استقرار اجتناب کنیم و بنابراین نسخه‌های ما بزرگ‌تر، کندتر و پرخطرتر می‌شوند.
“و هتک حرمت. هل دادن مستقیم به تولید غیرمسئولانه است!” یا آن؟ اگر کاری انجام می دهیم که حساس است، مانند کار با پرداخت ها یا داده ها، بله، محیط های آزمایشی خود را داشته باشید. البته ما باید از قضاوت خود استفاده کنیم، اما اگر بتوانیم موانع را برای استقرار در تولید از بین ببریم، آنگاه کار را آسان‌تر می‌کنیم، نه فقط انتشار ویژگی‌ها، بلکه رفع اشکال‌هایی که مطمئناً در هر نقطه‌ای اتفاق می‌افتد.
اگر مایکل برایژک بتواند این کار را با شرکتی انجام دهد که روزانه هزاران تراکنش را در یک وب‌سایت و پلتفرم بالغ پردازش می‌کند، اگر ریسک بسیار کمی وجود داشته باشد، می‌توانیم این کار را برای استارت‌آپ‌های خود انجام دهیم.
https://www.youtube.com/watch?v=z-ATZTUgaAo
البته، ما باید قبل از فشار، ویژگی های خود را آزمایش کنیم.
مصرف محصول خود را اندازه گیری کنید
ما می توانیم با مشتریان خود مصاحبه کنیم، که ایده خوبی است. اما آنچه مشتریان می گویند و انجام می دهند همیشه یکسان نیستند. وقتی محصول را در دست دارند، استفاده از چیزی مانند Hotjar یا ابزار دیگری برای اندازه‌گیری نحوه استفاده از محصول، بینش‌های بی‌درنگ را به ما می‌دهد. اگر فکر می‌کردیم مجموعه‌ای از ویژگی‌ها به کاربران ما کمک می‌کنند و بعد از انتشار متوجه می‌شدیم که هیچ‌کس از آنها استفاده نمی‌کند، می‌توانیم از اتلاف وقت بیشتر بر روی آن ویژگی جلوگیری کنیم یا از زاویه دیگری به ویژگی نزدیک شویم یا به چیز دیگری برویم.
IntelliSense را دوست خود قرار دهید
در حالی که من عاشق TypeScript هستم، برای یک ابزار جدید و امیدوارم محصول، از جاوا اسکریپت با JSDoc استفاده کردم. این به من امکان می دهد سریع بسازم، اما با JSDoc من IntelliSense را دریافت می کنم که به من در ساخت ابزار کمک می کند. در واقع، پس از 2 ساعت صرف نوشتن منطق اصلی ویژگی v0 برای یک محصول، نظرات JSDoc را گرفتم، آن را به Claude.ai دادم، سپس از آن خواستم که کد چسب را برای من بنویسد. و این کار را کرد!
وقتی برای IntelliSense بهینه‌سازی می‌کنیم، مانند مستنداتی است که به ما کمک می‌کند تا کد خود را در زمان واقعی بدون نیاز به خارج شدن از IDE بنویسیم. و نوشتن کد در آن نیز سریعتر می شود!
ابزارهای خود را مستند کنید
همه ما از مجموعه ای از ابزارهای مختلف استفاده می کنیم. اگر ما خوش شانس باشیم که استخدام‌ها و توسعه‌دهندگان جدید داشته باشیم، آنها شروع به معرفی ابزارهای خودشان خواهند کرد. قبل از اینکه متوجه شویم، همپوشانی داریم و مردم نمی‌دانند کجا چیزها را پیدا کنند. حتی اگر یک گروه یک نفره باشیم، حتی ممکن است همه ابزارهایی را که استفاده می کنیم فراموش کنیم.
برای من، مواردی مانند تجزیه و تحلیل، میزبانی ایمیل، میزبانی دامنه، نظارت بر آپتایم است. من حتی از یک README برای مستند کردن آن استفاده کردم. ما می توانیم از هر چیزی که دوست داریم استفاده کنیم. این باعث صرفه جویی در زمان می شود که بپرسیم از چه چیزی استفاده می کنیم.
در نهایت استرس نداشته باشید
استرس مانع از خلاقیت می شود. در حالی که ما فقط باید کارها را انجام دهیم، گاهی اوقات خلاقیت و درک اینکه یک راه ساده‌تر، سریعتر و بهتر برای انجام کاری در مقایسه با روشی که همیشه انجام داده‌ایم وجود دارد، می‌تواند مفید باشد. بنابراین از ضرب الاجل ها اجتناب کنید، به خصوص اگر استرس ایجاد کنند. در عوض، باید سعی کنیم ویژگی یا کاری را انتخاب کنیم که فکر می‌کنیم بیشترین تأثیر را روی هدف ما دارد که می‌تواند در سریع‌ترین زمان ممکن به آن دست پیدا کند، و سپس آن را انجام دهیم.
