Top 5 provocări în procesul de dezvoltare a produselor pentru infrastructura de e-mail

Infrastructura de e-mail este sistemul interconectat care permite trimiterea, primirea și stocarea mesajelor electronice. Ca atare, joacă un rol vital în facilitarea schimbului de informații, fie el B2B sau B2C.

În acest sens, Radicati Group Inc. estimează că numărul total de e-mailuri trimise se va apropia de 400 de miliarde în 2027. Iar numărul utilizatorilor din întreaga lume este de așteptat să ajungă la 5 miliarde, în același an.

Pe măsură ce volumul traficului de e-mail continuă să crească, importanța de a avea o infrastructură de e-mail robustă și fiabilă este greu de negat.

Cu toate acestea, dezvoltarea și menținerea unei infrastructuri de e-mail de încredere nu este lipsită de probleme. În acest articol, discutăm primele cinci provocări cu care se confruntă organizațiile în procesul de dezvoltare a produselor pentru infrastructura de e-mail și oferim soluții practice pentru a le depăși.

1: Scalabilitate

Provocarea

Deoarece traficul continuă să crească, infrastructura de e-mail poate avea dificultăți să facă față sarcinii. Companiile trebuie să ia măsuri preventive pentru a face față creșterii și pentru a evita întreruperile serviciilor.

Brainstormingul măsurilor în paralel cu dezvoltarea conceptului este favorabil. Dacă nu, dezvoltatorii trebuie să o facă cu lansarea MVP sau riscă următoarele:

• Pierderea productivității
• Scăderea satisfacției clienților
• Potențiale pierderi financiare
• Scăderea evaluărilor autorităților de domeniu
• Scăderea reputației expeditorului

Soluțiile:

• Infrastructură bazată pe cloud
• Echilibrarea sarcinii

Utilizarea infrastructurii bazate pe cloud

Cu infrastructura bazată pe cloud, dezvoltatorii profită de scalabilitatea și fiabilitatea serviciilor de e-mail de la terți. La rândul lor, ei asigură resursele necesare pentru a răspunde nevoilor crescânde ale clienților.

Sună promițător, dar cum funcționează de fapt?

Serviciile de e-mail ale terților folosesc centre de date mari, centralizate, pentru a stoca și procesa datele. Așadar, companiile de dezvoltare de software pot profita de cele mai noi tehnologii și resurse fără a investi în propriile lor. Și asta ajută la uciderea a două păsări dintr-o singură piatră:

1. Abordarea reduce considerabil costurile operaționale.
2. De asemenea, oferă organizațiilor o soluție scalabilă pentru a satisface nevoile lor în creștere.

Lucrul important de subliniat aici este că ar trebui să dezvoltați infrastructura bazată pe cloud, pas la un moment dat. Aceasta înseamnă că cel mai bine este să începeți să rulați unele sarcini în cloud, apoi să scalați sarcinile în sine în funcție de încărcarea curentă (în acest caz, volumul de e-mailuri sau solicitări ale utilizatorilor).

Dar sarcinile bazate pe cloud nu ar trebui scalate ad-hoc, este crucial să se determine strategia de dezvoltare a produsului respectiv. Și mai important, trebuie să știi dacă există provocări și blocaje asociate cu asta.

Implementarea echilibrării sarcinii

Înainte de a vă scufunda puțin mai adânc, rețineți că echilibrarea sarcinii ar trebui implementată împreună cu infrastructura bazată pe cloud. În cel mai bun caz, în cadrul unei singure etape de dezvoltare a produsului.

Acum, echilibrarea încărcării se referă la distribuția sarcinilor de lucru în mai multe arhitecturi și sarcini în cloud. Beneficiul cheie este că produsul existent devine capabil să gestioneze un volum crescut, chiar și la traficul de vârf.

Deoarece încărcăturile de lucru sunt distribuite pe mai multe servere, niciun server nu este afectat de volumul traficului de e-mail. Prin urmare, șansele de întrerupere a serviciului și blocaje sunt semnificativ mai mici.

Mai bine, algoritmii de echilibrare a sarcinii pot fi utilizați pentru a ajusta dinamic distribuția sarcinilor de lucru, de obicei pe baza a doi factori:

1. Numărul de cereri.
2. Puterea de procesare a fiecărui server.

Construirea unei platforme de cazare infernale

În 2012, procesul de dezvoltare a produselor Airbnb se afla într-o etapă esențială.

Ei loveau publicul țintă chiar în cap, scalând întreaga platformă. Dar feedbackul utilizatorilor a relevat un număr alarmant de cazuri marginale care implică cereri de modificare, dispute și rambursări. La acea vreme, toate acestea erau gestionate manual prin e-mail, fără backend care să sprijine procesarea cererilor, ceea ce punea o presiune semnificativă asupra extinderii afacerii.

Airbnb se confrunta cu o alegere riscantă: angajați peste 1000 de oameni într-un an sau construiți un cadru automat pentru a gestiona cazurile marginale.

Da, au ales-o pe cea din urmă.

Jonathan Golden, manager de produs Airbnb la acea vreme, a trebuit să acorde priorități fără milă. Scopul principal a fost crearea unui plan pentru o soluție cloud automatizată (cadru de backend) care să gestioneze și să clasifice cazurile marginale.

Cu cadrul implementat, Airbnb a fost deblocat rapid și a continuat să crească de la 300% la 600% pe an. Rețineți că aceste procente se referă la creșterea exponențială timpurie a Airbnb.

Cu toate acestea, există mai multe concluzii despre dezvoltarea de produse din acest exemplu decât simpla mutare a totul în cloud și automatizarea fluxurilor de lucru.

• Este esențial să faceți mai întâi o provocare tehnică manual. În caz contrar, dezvoltatorii ar putea să nu fie conștienți de problemele de rădăcină.
• O companie nu ar trebui să aștepte prea mult înainte de a aplica automatizarea scalării, echilibrarea sarcinii sau orice altceva. Dacă nu o faci la timp, este posibil ca provocările să crească atât de mult încât să devină mult mai greu să le depășești.
• Încercați întotdeauna să creați o soluție sau un cadru care ar putea fi aplicat altor probleme din foaia de parcurs al produsului. Făcând asta, echipele dvs. sunt mult mai agile.

2: Securitate

Provocarea

Securitatea infrastructurii de e-mail, sau lipsa acesteia, este vitală, deoarece afectează direct capacitatea organizațiilor de a comunica eficient cu potențialii clienți.

O echipă de dezvoltare a produsului trebuie să abordeze această provocare într-un stadiu incipient, cu mult înainte de produsul minim viabil. Dar nu se oprește aici. Auditurile regulate de securitate ar trebui să fie o prioritate chiar dacă aveți de-a face cu un produs finit.

Deoarece informațiile confidențiale sunt adesea schimbate prin e-mail, o încălcare a securității poate duce la expunerea informațiilor sensibile. Acest lucru poate avea consecințe grave pentru organizații, inclusiv daune reputaționale, pierderea încrederii clienților și potențiale repercusiuni legale.

În plus, este important ca toate echipele să înțeleagă potențialele riscuri de securitate pentru a preveni încălcările care pot eluda criptarea și protocoalele de securitate. Un astfel de risc este ingineria socială, dar mai multe despre asta în una dintre secțiunile următoare.

Soluțiile:

• Criptare
• Protocoale securizate
• Actualizări regulate ale măsurilor de securitate

Protocoalele securizate, cum ar fi SSL și TLS, oferă servicii de criptare și autentificare pentru datele de e-mail în tranzit. Din acest motiv, ele pot fi considerate ca prima linie de apărare în foaia de parcurs pentru infrastructura de e-mail. În plus, organizațiile ar trebui să revizuiască și să actualizeze în mod regulat măsurile de securitate internă.

Cum?

De exemplu, o companie care dezvoltă software-ul trebuie să stabilească politici interne pentru ingineri și alte părți interesate pentru a limita accesul la baza de coduri, gits etc. În același timp, compania ar trebui să aibă protocoale clare despre cum și de ce cuiva i se poate acorda mai mult privilegii de acces.

Echipele de dezvoltare folosesc de obicei principiul privilegiilor listei pentru a atinge un nivel mai ridicat de securitate. Aceasta înseamnă că se oferă mai mult acces la cerere și foarte puțini oameni au acces la orice.

Am menționat anterior SSL și TLS care criptează datele în mișcare (date în tranzit). Dar companiile trebuie să ia în considerare și criptarea datelor în repaus și să stabilească diferite niveluri de acces la acele date.

„Pinky promit, nu te vom sparge!”

Acesta este oarecum un caz de afaceri negativ, dar arată clar că există întotdeauna două aspecte ale securității – software-ul și oamenii.

În ianuarie 2023, Mailchimp a suferit o breșă de securitate (a treia în decurs de 12 luni), expunând datele sensibile ale a 133 de clienți. Și ingineria socială a fost strategia pe care escrocii au folosit-o pentru a avea acces la informații sensibile.

Practic, asta însemna că fraudatorii online au folosit angajații Mailchimp nebănuiți și probabil fără experiență pentru a obține acces la date protejate. Escrocii au phishing angajații pentru acreditările lor, piratand astfel oamenii, nu sistemul în sine. Cu toate acestea, au fost expuse informațiile sensibile a aproximativ 133 de clienți.

Concluzia este că aspectul tehnic al securității trebuie să fie antiglonț. Dar, în același timp, o companie trebuie să stabilească proceduri și să educe angajații cu privire la modul de a evita să devină phishing sau orice alt tip de victimă online.

3: Fiabilitate

Provocarea

Fiabilitatea determină capacitatea unui sistem de a funcționa corect și consecvent în timp. Ca atare, se numără printre cele mai mari obstacole în timpul diferitelor iterații ale unui proces de dezvoltare a unui nou produs.

De ce?

Fără fiabilitate, utilizatorii nu pot fi siguri că e-mailurile lor vor fi livrate și primite conform așteptărilor, distrugând în cele din urmă propunerea de valoare. Sigur, acesta este cazul infrastructurii de e-mail, dar aici este o imagine mai bună.

Fiabilitatea produsului final în SaaS afectează direct reputația mărcii și capacitatea acestuia de a livra. Fie că este un MVP sau un produs deja de succes, trebuie să reziste la diferite tipuri de eșecuri, cum ar fi utilizarea crescută a memoriei RAM, vârfuri în solicitările utilizatorilor, încărcări neașteptate de infrastructură etc.

Soluția:

• Implementarea sistemelor de redundanță și backup
• Monitorizarea regulată a infrastructurii

Redundanța presupune a avea mai multe copii ale acelorași date stocate în locații diferite. Deci, dacă un sistem eșuează, există o copie de rezervă care trebuie utilizată. Mai multe tehnologii permit acest lucru, în special echilibrarea încărcării, în care e-mailurile sunt distribuite pe mai multe servere pentru a reduce riscul de eșec.

Apoi, monitorizarea regulată a infrastructurii oferă valori care permit dezvoltatorilor să detecteze și să rezolve problemele înainte ca acestea să devină probleme reale. Acest lucru se poate face cu instrumente de monitorizare și verificări regulate ale sistemului. Sau, uneori, echipele de dezvoltare pot aplica analiza SWOT în timpul testării conceptului pentru a determina cele mai bune abordări.

Vorbind de monitorizare, cel mai bine este dacă dezvoltatorii construiesc alarme pe deasupra monitorizării. De exemplu, alarmele ar trebui setate pentru următoarele circumstanțe:

1. Dacă procesele încep să consume mai multă memorie.
2. Dacă există probleme specifice de prelucrare a datelor/calculator.
3. În cazul a 500 de răspunsuri de cod.

Aceste alarme se referă la asistența internă pentru arhitectură și la gestionarea produselor la gardă; ambele ar trebui stabilite în timpul procesului de dezvoltare a software-ului sau odată cu lansarea produsului soft.

În limba engleză simplă, când există o alarmă declanșată de un eveniment îngrijorător, un inginer ar trebui să sară direct pe ea, chiar dacă este în miezul nopții.

Cum au făcut uriașii

Google însuși este un exemplu excelent de strategie de proiectare a unui produs care a depășit cu succes provocările de fiabilitate de la început. Infrastructura lor este proiectată pentru a prezenta mai multe niveluri de redundanță. Acest lucru îi permite motorului de căutare să se asigure că e-mailurile utilizatorilor sunt livrate și primite conform așteptărilor, chiar și în cazul unei defecțiuni interne.

Un alt exemplu este Microsoft, care a implementat o infrastructură de e-mail extrem de fiabilă prin utilizarea sistemelor de echilibrare a încărcăturii și de rezervă. Aceste măsuri au ajutat Microsoft să se asigure că serviciul său de e-mail rămâne extrem de fiabil, chiar și în fața creșterii semnificative și a cererii crescute.

Dar, din păcate, nu mai este așa. În timpul ciclului de viață al produsului, au existat câteva puncte de inflexiune în care Microsoft ar fi putut eșua să efectueze o cercetare de piață adecvată și o analiză a concurenței - mai multe despre asta în secțiunea Gestionarea așteptărilor de performanță .

4: Interoperabilitate

Provocarea

Interoperabilitatea indică capacitatea infrastructurii de e-mail sau a oricărui serviciu SaaS de a se integra și de a funcționa bine cu alte aplicații.

De obicei, integrările ar trebui să includă:

1. Managementul relatiilor cu clientii (CRM)
2. Planificarea resurselor întreprinderii (ERP)
3. Stocare a datelor

Care este beneficiul?

Abilitatea de a face schimb de informații fără probleme între diferite aplicații ajută companiile să ia decizii informate, bazate pe date. În plus, le permite să eficientizeze procesele legate de produs. Bonusul este că interoperabilitatea ridicată oferă și o experiență mult mai bună pentru utilizator.

Doar rețineți că acest aspect ar trebui abordat atunci când faceți brainstorming conceptul de produs. Și merită să cântăriți opțiunile de integrare față de ceea ce este disponibil pe piața țintă.

Soluția:

• Standarde deschise
• Compatibilitate multiplatformă

Standardele deschise sunt specificații disponibile public care permit diferitelor sisteme să lucreze împreună.

Standardele cheie deschise cu infrastructura de e-mail includ Protocolul simplu de transfer de e-mail (SMTP), Protocolul Post Office versiunea 3 (POP3) și Protocolul de acces la mesaje Internet (IMAP).

În ceea ce privește compatibilitatea, infrastructura de e-mail trebuie să fie proiectată pentru a funcționa cu diferite sisteme de operare (Windows, macOS și Linux), precum și cu diferite browsere web (Google Chrome, Mozilla Firefox, Safari etc.).

Cu toate acestea, încorporarea standardelor deschise și asigurarea compatibilității între platforme nu este lipsită de provocări. Luați SMTP de exemplu, dezvoltatorii trebuie adesea să-i facă ajustări specifice și poate chiar să adauge criptare. Pentru a realiza cu ușurință aceasta și alte remedieri specifice produsului, este recomandabil să utilizați platforme interconectate, cum ar fi AWS.

În cele din urmă, echipele de dezvoltare trebuie să acorde o atenție deosebită semnăturilor, soluțiilor de spam, înregistrărilor DNS și altele, în ceea ce privește ca software-ul lor să funcționeze bine cu integrări terțe.

Pe scurt, acest lucru se rezumă la respectarea formatelor și protocoalelor standard în fiecare etapă a procesului de dezvoltare a produsului. Ulterior, inginerii pot personaliza fluxurile de lucru back-end și front-end-ul acolo unde este necesar.

Tăiați-ne puțin Slack

Dacă credeți că Slack a reușit să reinventeze modul în care colaborăm, nu veți greși. Dar întrebarea este cum au făcut-o.

Să ignorăm faptul că Slack a avut o soluție stabilă în etapa de lansare pe piață. Și să uităm de o strategie de marketing inteligentă care a reușit să transforme hoarde de lucrători IT frustrați. Important aici este ce se întâmplă după conversie.

În primul rând, bara pentru a intra în Slack este foarte scăzută. Cu toate acestea, acoperă majoritatea cazurilor de utilizare pe care vi le puteți imagina. Apoi, migrarea echipelor dvs. la Slack este destul de simplă. Gestionarea utilizatorilor este fără probleme, iar lista de integrări continuă și continuă...

În funcție de dimensiunea și domeniul de aplicare al afacerii dvs., puteți conecta aplicațiile Jira, Notion, Coda, Google și altele pentru a avea toate notificările și canalele de date sub un singur acoperiș. Toate acestea în câteva zile sau chiar ore.

Ceea ce este cel mai impresionant este că interoperabilitatea Slack este aproape setată și uită. Odată ce ați integrat tot ce aveți nevoie, sunteți întotdeauna la un clic distanță de o sursă de date sau de comunicare. Și această experiență de utilizator este greu de rivalizat.

5: Gestionarea așteptărilor de performanță

Provocarea

Provocarea gestionării așteptărilor de performanță constă în asigurarea faptului că produsul îndeplinește nevoile și cerințele utilizatorilor finali. Din acest motiv, este sigur să echivalezi așteptările de performanță cu așteptările utilizatorilor, în special atunci când se dezvoltă SaaS.

Pentru a fi clar, succesul unui produs de infrastructură de e-mail sau al oricărui SaaS depinde în mare măsură de cât de bine îl percep utilizatorii finali și clienții țintă. Adică, cât de bine satisface produsul așteptările de performanță ale utilizatorilor.

Odată cu creșterea dependenței de e-mail, utilizatorii se așteaptă ca infrastructura să fie sigură, rapidă și fiabilă. În plus, utilizatorii doresc să fie:

• Ușor de folosit
• Accesibil de pe mai multe dispozitive
• Să fiți capabil să gestionați traficul de e-mail la scară

Soluția:

• Testare
• Optimizare
• Comunicare clară
• Bucle de feedback

Cu riscul de a afirma că este evident, testarea și optimizarea regulate trebuie să fie o parte integrantă a oricărui proces de dezvoltare a produsului. Poate implica efectuarea de sondaje, focus grupuri, testare A/B pentru a colecta feedback-ul utilizatorilor etc.

Comunicarea clară merge mână în mână cu testarea, deoarece ajută la construirea încrederii și a transparenței. Adesea, comunicarea include actualizări publice regulate cu privire la procesul de dezvoltare, informând utilizatorii despre modificările de infrastructură și abordând orice problemă de performanță generată de utilizatori.

Toată comunicarea și testarea oferă dezvoltatorilor feedback calificat al clienților, care, la rândul său, ajută la îndeplinirea nevoilor și așteptărilor acestora. Pasul critic aici este integrarea feedback-ului dat în procesele de dezvoltare a produsului.

Pur și simplu, asta înseamnă să fii vigilent la toate dezavantajele unui sistem. Poate chiar făcând analize de afaceri pentru a înțelege mai bine ce metodologie să aplice în îmbunătățirea produsului fără a afecta comercializarea acestuia.

Apoi, pasul crucial este transformarea tuturor constatărilor în sarcini și actualizări acționabile pentru a vă eficientiza și mai mult software-ul.

Dar, atunci când testați și monitorizați aplicația dvs., există anumite lucruri de reținut. De exemplu, testele de stres determină dacă codul rulează lent. Cu toate acestea, faptul că ceva funcționează lent nu necesită o actualizare. Echipele de dezvoltare au nevoie de o înțelegere solidă a actualizărilor care sunt critice pentru performanță și care pot fi prioritizate pentru utilizarea optimă a resurselor.

Bătălia uriașilor

După cum am menționat mai devreme, această secțiune explorează domeniile în care Microsoft a eșuat posibil la așteptările de performanță, dând loc concurenților să prospere. Există un pic de poveste, care implică atât Apple, cât și Google.

Până în momentul în care au lansat MPP (Mail Privacy Protection) în septembrie 2021, Apple a învins deja Google pentru cota de piață a clienților de e-mail. La acea vreme, cota Apple era aproape de 59%, Google era în jur de 28%, dar Outlook-ul Microsoft era mult în urmă cu aproximativ 5%.

Acum, care ar putea fi motivele pentru care Microsoft a fost bătut la pumn?

Pentru a găsi răspunsul, ar trebui să privim puțin mai departe în trecut.

Google a lansat Gmail pe 1 aprilie, acum aproape două decenii. Și nu a durat mult până când Microsoft și-a dat seama că nu era o glumă a lui Aprilie. Tatăl Windows a împins din greu să rămână dominant timp de aproximativ zece ani. Dar odată ce Gmail a preluat piața în 2015, a fost în mare parte o spirală descendentă pentru Outlook.

Dar de ce?

Este sigur să argumentăm că motivele sunt așteptările de performanță eșuate. Practic, Gmail a fost mai rapid și mai ușor de utilizat și a oferit o interfață mult mai simplificată. Împreună cu mai multe funcții și cu spațiu de stocare mult mai mare (1 GB – 500 de ori mai mult decât Outlook la acea vreme), nu este surprinzător că Gmail a câștigat.

Avanză rapid până astăzi și este clar că Google s-ar putea afla într-o situație similară ca Microsoft acum un deceniu. Acum, așteptarea cheie de performanță care a eșuat este urmărirea. Având în vedere numărul de e-mailuri primite, fie ele de marketing sau tranzacționale, oamenii preferă să-și păstreze evenimentele de e-mail ascunse.

Sigur, faptul că devine din ce în ce mai dificil să urmăriți ratele de deschidere, locațiile geografice și dispozitivele dă arsuri la stomac. Dar statisticile arată că exact asta se așteaptă utilizatorii.

Echipele de dezvoltare a e-mailului Apple au observat tendința de la început și au fost printre primii care au oferit o soluție viabilă pentru a menține zgomotul prin e-mail la minimum. Acest tip de așteptări de performanță, monitorizare și actualizări ar putea determina Apple să domine spațiul clientului de e-mail în viitorul apropiat.

Construiește produse bune

Până acum, ar trebui să aveți o înțelegere solidă a provocărilor critice din procesul de dezvoltare a produsului. Pentru a evidenția, nu prea contează ce tip de produs dezvoltați.

Provocările descrise sunt agnostice pentru nișă și, în mare măsură, pentru ciclul de dezvoltare a produsului. Chiar dacă sunteți în stadiul de idee, cu siguranță doriți ca produsul să fie sigur, fiabil și scalabil. Apoi, când ajungeți la etapa de pornire, nu vă opriți cu screening-ul și validarea ideilor de produs.

În cele din urmă, este important să ne amintim că procesul de dezvoltare a produsului necesită multă cercetare, analiză și planificare a implementării la fiecare pas. Vestea bună este că acest articol ți-a oferit o foaie de parcurs solidă și domenii cheie pe care să te concentrezi.