[et_pb_section fb_built=”1″ admin_label=”section” _builder_version=”3.22″][et_pb_row admin_label=”row” _builder_version=”3.25″ background_size=”initial” background_position=”top_left” background_repeat=”repeat”][et_pb_column type=”4_4″ _builder_version=”3.25″ custom_padding=”|||” custom_padding__hover=”|||”][et_pb_text admin_label=”Text” _builder_version=”4.5.1″ text_font_size=”15px” text_line_height=”1.9em” background_size=”initial” background_position=”top_left” background_repeat=”repeat”]<\/p>\n
Een poosje terug kwam ik via Facebook op een blog van Hotjar terecht: \u201cApp mistakes: the 10 lessons we learned launching (& killing) our $200K mobile app<\/a>\u201d. Hotjar is een verzameling tools voor o.a. het analyseren van gedrag van bezoekers op een website. In het betreffende artikel vertelt de auteur dat ze in 2018 hun mobiele app de nek hebben omgedraaid, wat natuurlijk een pijnlijk proces was nadat er ruim 3.500 uur ontwikkeling in was gestopt. De auteur beschrijft vier belangrijke fouten die zijn gemaakt, waardoor de app volgens hen gedoemd was te mislukken. Vervolgens worden de stappen benoemd die ze zouden nemen als ze het allemaal over mochten doen.<\/strong><\/p>\n Zelf hebben we eind 2018 onze eigen app voor Provisior<\/a> gelanceerd, waarmee medewerkers een password reset kunnen uitvoeren en digitale workflows kunnen afhandelen. Na het lezen van het artikel was ik vanzelfsprekend \u201cgetriggerd\u201d. Hoe hebben wij het gedaan? Hebben wij dezelfde fouten gemaakt\u2026 en is onze app ook gedoemd om te mislukken?\u00a0Het leek me daarom interessant om in te zoomen op deze vier fouten en te kijken hoe wij het gedaan hebben.<\/p>\n <\/strong><\/p>\n Klanten van Hotjar zaten helemaal niet te wachten op een app, beschrijft de auteur. En ook de vraag wat de app zou moeten kunnen is vooraf nooit gesteld aan gebruikers. Deze eerste fout hebben wij in ieder geval niet gemaakt. Het idee van een app hebben we vooraf bij diverse bestaande klanten en partners getoetst, en ook over de functies die we voor ogen hadden hebben we met ze gespard. De enthousiaste reacties bevestigden ons idee dat we op de juiste weg waren met de ontwikkeling van de Provisior app.<\/p>\n \n Ook hadden wij nog geen ervaring met het ontwikkelen van een native mobile app. Er is ook echt veel tijd ingestoken, maar dat had een belangrijke reden. Vanaf dag 1 heeft security een belangrijke rol gespeeld. Met een app van elke plek ter wereld een handeling kunnen uitvoeren binnen een bedrijfsnetwerk\u2026 dat moet veilig zijn. We zijn er van overtuigd dat het ook veilig is, juist doordat we veel tijd hebben besteed aan de manier waarop een mobiel apparaat gekoppeld wordt en de ontwikkelinspanningen die daarbij kwamen kijken. En we hebben ontzettend veel geleerd, soms door vallen en opstaan. Maar h\u00e9, dat hoort ook bij software ontwikkeling.<\/p>\n \n Dit is iets waar we goed rekening mee hebben gehouden door naar onze roadmap te blijven kijken. Klanten vroegen om een app, dus de focus hierop was een juiste keuze. Echter, we hebben niet alleen aan de app gewerkt, het reguliere onderhoud op Provisior liep gewoon door en we hebben ook andere \u201cepics\u201d afgerond, zoals het automatisch kunnen anonimiseren van een database in het kader van GDPR, en simpele doch zeer waardevolle verbeteringen als het kunnen fiatteren van meerdere aanvragen tegelijk.<\/p>\n \n Het toepassen van \u201cMVP\u201d bij het ontwikkelen van nieuwe software applicaties of onderdelen hiervan is iets wat we al jaren doen. Binnen ons Scrum-proces is dit \u00e9\u00e9n van de basisprincipes die we hanteren. Zoals eerder vermeld, met onze app kan een password reset worden uitgevoerd en kunnen aanvragen digitaal goedgekeurd worden. Dit zijn twee van de meest gevraagde functies voor de app en lenen zich ook uitstekend voor een mobiel apparaat. Natuurlijk hadden we genoeg idee\u00ebn voor andere toepassingen, zoals het kunnen delegeren van je rol (wat praktisch is als je ziek bent of wanneer je dit vergeet te doen voor je op vakantie gaat). Maar door het relatief klein te houden hebben we sinds eind vorig jaar een app die enthousiast gebruikt wordt door klanten en hebben we al diverse nieuwe idee\u00ebn en verbeteringen verwerkt.<\/p>\n Terugkijkend op dit proces kan ik met gepaste trots zeggen dat de meeste fouten die Hotjar zegt te hebben gemaakt, wij (al dan niet bewust) niet gemaakt hebben. We hadden een idee, die we getoetst hebben bij klanten, en we hebben het bewust klein gehouden middels \u201cMVP\u201d. Een aanpak die we in de toekomst zullen blijven toepassen. En dat zien we ook terug bij de app. Onze klanten maken er steeds meer gebruik van en in de gesprekken met onze klanten merken we dat het als een pr\u00e9 wordt ervaren.<\/p>\n [\/et_pb_text][et_pb_team_member name=”Stefan Krul-Donkersloot” position=”Senior Consultant” image_url=”http:\/\/www.provisior.nl\/wp-content\/uploads\/2020\/11\/Stefan-280×300.png” linkedin_url=”https:\/\/www.linkedin.com\/authwall?trk=gf&trkInfo=AQH6mCwP_Fz_tQAAAXZm4XPgIDauFKNv_wQ44wNW5Dk56EgdVffahG03iJPv228xb7YwD-aOPZrnwWCq-s0i290y9McoNvZepg7tPwt_9Rdvy3-o97HVU-lPgYxfpJWqOt-dRWc=&originalReferer=https:\/\/www.provisior.nl&sessionRedirect=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fstefan-krul-donkersloot-a29b9a142%2F” icon_color=”#d258a0″ _builder_version=”4.7.7″ _module_preset=”default” header_text_align=”left” header_line_height=”2em” body_font=”||||||||” body_line_height=”0em” position_font=”|300|||||||” position_text_align=”left” position_text_color=”#45a3be” text_orientation=”left” max_width=”18%” module_alignment=”left” border_radii_image=”on|10px|10px|10px|10px” locked=”off”][\/et_pb_team_member][\/et_pb_column][\/et_pb_row][\/et_pb_section]<\/p>\n","protected":false},"excerpt":{"rendered":" Een poosje terug kwam ik via Facebook op een blog van Hotjar terecht: \u201cApp mistakes: the 10 lessons we learned launching (& killing) our $200K mobile app\u201d. Hotjar is een verzameling tools voor o.a. het analyseren van gedrag van bezoekers op een website. In het betreffende artikel vertelt de auteur dat ze in 2018 hun […]<\/p>\n","protected":false},"author":4,"featured_media":4844,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"on","_et_pb_old_content":"Een poosje terug kwam ik via Facebook op een blog van Hotjar terecht: \u201cApp mistakes: the 10 lessons we learned launching (& killing) our $200K mobile app<\/a>\u201d. Hotjar is een verzameling tools voor o.a. het analyseren van gedrag van bezoekers op een website. In het betreffende artikel vertelt de auteur dat ze in 2018 hun mobiele app de nek hebben omgedraaid, wat natuurlijk een pijnlijk proces was nadat er ruim 3.500 uur ontwikkeling in was gestopt. De auteur beschrijft vier belangrijke fouten die zijn gemaakt, waardoor de app volgens hen gedoemd was te mislukken. Vervolgens worden de stappen benoemd die ze zouden nemen als ze het allemaal over mochten doen.\r\n\r\nZelf hebben we eind 2018 onze eigen app voor Provisior<\/a> gelanceerd, waarmee medewerkers een password reset kunnen uitvoeren en digitale workflows kunnen afhandelen. Na het lezen van het artikel was ik vanzelfsprekend \u201cgetriggerd\u201d. Hoe hebben wij het gedaan? Hebben wij dezelfde fouten gemaakt\u2026 en is onze app ook gedoemd om te mislukken?\r\n\r\nHet leek me daarom interessant om in te zoomen op deze vier fouten en te kijken hoe wij het gedaan hebben:\r\n\r\n\u201cMistake #1: We didn't validate the idea before we acted on it\u201d<\/strong>\r\n\r\nKlanten van Hotjar zaten helemaal niet te wachten op een app, beschrijft de auteur. En ook de vraag wat de app zou moeten kunnen is vooraf nooit gesteld aan gebruikers. Deze eerste fout hebben wij in ieder geval niet gemaakt. Het idee van een app hebben we vooraf bij diverse bestaande klanten en partners getoetst, en ook over de functies die we voor ogen hadden hebben we met ze gespard. De enthousiaste reacties bevestigden ons idee dat we op de juiste weg waren met de ontwikkeling van de Provisior app.\r\n\r\n\u201cMistake #2: We underestimated the resources required to build for mobile\u201d<\/strong>\r\n\r\nOok hadden wij nog geen ervaring met het ontwikkelen van een native mobile app. Er is ook echt veel tijd ingestoken, maar dat had een belangrijke reden. Vanaf dag 1 heeft security een belangrijke rol gespeeld. Met een app van elke plek ter wereld een handeling kunnen uitvoeren binnen een bedrijfsnetwerk\u2026 dat moet veilig zijn. We zijn er van overtuigd dat het ook veilig is, juist doordat we veel tijd hebben besteed aan de manier waarop een mobiel apparaat gekoppeld wordt en de ontwikkelinspanningen die daarbij kwamen kijken. En we hebben ontzettend veel geleerd, soms door vallen en opstaan. Maar h\u00e9, dat hoort ook bij software ontwikkeling.\r\n\r\n\u201cMistake #3: We didn\u2019t focus on what would have the biggest impact for Hotjar\u201d<\/strong>\r\n\r\nDit is iets waar we goed rekening mee hebben gehouden door naar onze roadmap te blijven kijken. Klanten vroegen om een app, dus de focus hierop was een juiste keuze. Echter, we hebben niet alleen aan de app gewerkt, het reguliere onderhoud op Provisior liep gewoon door en we hebben ook andere \u201cepics\u201d afgerond, zoals het automatisch kunnen anonimiseren van een database in het kader van GDPR, en simpele doch zeer waardevolle verbeteringen als het kunnen fiatteren van meerdere aanvragen tegelijk.\r\n\r\n\u201cMistake #4: We didn\u2019t think Minimum Viable Product (MVP) and lost sight of the original goal\u201d<\/strong>\r\n\r\nHet toepassen van \u201cMVP\u201d bij het ontwikkelen van nieuwe software applicaties of onderdelen hiervan is iets wat we al jaren doen. Binnen ons Scrum-proces is dit \u00e9\u00e9n van de basisprincipes die we hanteren. Zoals eerder vermeld, met onze app kan een password reset worden uitgevoerd en kunnen aanvragen digitaal goedgekeurd worden. Dit zijn twee van de meest gevraagde functies voor de app en lenen zich ook uitstekend voor een mobiel apparaat. Natuurlijk hadden we genoeg idee\u00ebn voor andere toepassingen, zoals het kunnen delegeren van je rol (wat praktisch is als je ziek bent of wanneer je dit vergeet te doen voor je op vakantie gaat). Maar door het relatief klein te houden hebben we sinds eind vorig jaar een app die enthousiast gebruikt wordt door klanten en hebben we al diverse nieuwe idee\u00ebn en verbeteringen verwerkt.\r\n\r\nTerugkijkend op dit proces kan ik met gepaste trots zeggen dat de meeste fouten die Hotjar zegt te hebben gemaakt, wij (al dan niet bewust) niet gemaakt hebben. We hadden een idee, die we getoetst hebben bij klanten, en we hebben het bewust klein gehouden middels \u201cMVP\u201d. Een aanpak die we in de toekomst zullen blijven toepassen.\r\n\r\nEn dat zien we ook terug bij de app. Onze klanten maken er steeds meer gebruik van en in de gesprekken met onze klanten merken we dat het als een pr\u00e9 wordt ervaren.","_et_gb_content_width":"","footnotes":""},"categories":[50],"tags":[],"class_list":["post-4792","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"yoast_head":"\n\u201cMistake #1: We didn’t validate the idea before we acted on it\u201d<\/strong><\/h2>\n
\u201cMistake #2: We underestimated the resources required to build for mobile\u201d<\/strong><\/h2>\n
\u201cMistake #3: We didn\u2019t focus on what would have the biggest impact for Hotjar\u201d<\/strong><\/h2>\n
\u201cMistake #4: We didn\u2019t think Minimum Viable Product (MVP) and lost sight of the original goal\u201d<\/strong><\/h2>\n