Русский
Русский
English
Статистика
Реклама

Mvp

Пишем full stack монолит с помощью Angular Universal NestJS PostgreSQL

10.08.2020 02:14:34 | Автор: admin
Привет, Хабр!

В этой статье мы создадим готовый шаблон-монолит, который можно брать за основу нового fullstack приложения как скелет для навешивания функционала.


Эта статья будет полезна, если вы:


  • Начинающий fullstack-разработчик;
  • Стартапер, который пишет MVP чтобы проверить гипотезу.

Почему выбрал такой стек:


  • Angular: имею много опыта в нем, люблю строгую архитектуру и Typescript из коробки, выходец из .NET
  • NestJS: тот-же язык, та-же архитектура, быстрое написание REST API, возможность в дальнейшем пересесть на Serverless (дешевле виртуалки)
  • PostgreSQL: Собираюсь хоститься в Яндекс.Облаке, на минималках дешевле на 30% чем MongoDB

Прайс яндекса


Прежде чем написать статью, поискал на хабре статьи про подобный кейс, нашел следующее:



Из этого ничего не описывает "скопировал и вставил" или дает ссылки на то что еще нужно дорабатывать.


Оглавление:


1. Создаем Angular приложение и добавляем библиотеку компонентов ng-zorro
2. Устанавливаем NestJS и решаем проблемы с SSR
3. Делаем API на NestJS и подключаем к фронту
4. Подключаем базу данных PostgreSQL



1. Создаем Angular приложение


Установим Angular-CLI чтобы создавать SPA-сайты на Ангуляре:


npm install -g @angular/cli

Создадим Angular приложение с помощью следующей команды:


ng new angular-habr-nestjs

Далее переходим в папку приложения и запускаем, чтобы проверить работоспособность:


cd angular-habr-nestjsng serve --open

Статическое SPA-приложение на Angular


Приложение создалось. Подключаем библиотеку NG-Zorro:


ng add ng-zorro-antd

Далее выбираем следующие конфигурации библиотеки:


? Enable icon dynamic loading [ Detail: https://ng.ant.design/components/icon/en ] Yes? Set up custom theme file [ Detail: https://ng.ant.design/docs/customize-theme/en ] No? Choose your locale code: ru_RU? Choose template to create project: sidemenu

Эта конфигурация заменит содержимое app.component на дизайн с менюшкой слева, футером и хедером и подключит локализацию на русском языке:


Подключили NG-Zorro


В данной статье мы отобразим список данных для наглядности, поэтому добавим простенькую табличку в компоненте src/app/pages/welcome, который сгенерил NG-Zorro:
Пример взят отсюда:
https://ng.ant.design/components/table/en


// welcome.component.html<nz-table #basicTable [nzData]="items$ | async"> <thead> <tr>  <th>Name</th>  <th>Age</th>  <th>Address</th> </tr> </thead> <tbody> <tr *ngFor="let data of basicTable.data">  <td>{{ data.name }}</td>  <td>{{ data.age }}</td>  <td>{{ data.address }}</td> </tr> </tbody></nz-table>

// welcome.module.tsimport { NgModule } from '@angular/core';import { WelcomeRoutingModule } from './welcome-routing.module';import { WelcomeComponent } from './welcome.component';import { NzTableModule } from 'ng-zorro-antd';import { CommonModule } from '@angular/common';@NgModule({ imports: [  WelcomeRoutingModule,  NzTableModule, // Добавили для таблицы  CommonModule // Добавили для пайпа async ], declarations: [WelcomeComponent], exports: [WelcomeComponent]})export class WelcomeModule {}

// welcome.component.tsimport { Component, OnInit } from '@angular/core';import { Observable, of } from 'rxjs';import { HttpClient } from '@angular/common/http';import { share } from 'rxjs/operators';@Component({ selector: 'app-welcome', templateUrl: './welcome.component.html', styleUrls: ['./welcome.component.scss']})export class WelcomeComponent implements OnInit { items$: Observable<Item[]> = of([  {name: 'Вася', age: 24, address: 'Москва'},  {name: 'Петя', age: 23, address: 'Лондон'},  {name: 'Миша', age: 21, address: 'Париж'},  {name: 'Вова', age: 23, address: 'Сидней'} ]); constructor(private http: HttpClient) { } ngOnInit() { } // Сразу напишем метод к бэку, понадобится позже getItems(): Observable<Item[]> {  return this.http.get<Item[]>('/api/items').pipe(share()); }}interface Item { name: string; age: number; address: string;}

Получилось следующее:


Табличка NG-Zorro



2. Устанавливаем NestJS


Далее установим NestJS таким образом, чтобы он предоставил Angular Universal (Server Side Rendering) из коробки и напишем пару ендпоинтов.


ng add @nestjs/ng-universal

После установки, запускаем наш SSR с помощью команды:


npm run serve

И вот уже первый косяк :) У нас появляется следующая ошибка:


TypeError: Cannot read property 'indexOf' of undefined  at D:\Projects\angular-habr-nestjs\node_modules\@nestjs\ng-universal\dist\utils\setup-universal.utils.js:35:43  at D:\Projects\angular-habr-nestjs\dist\server\main.js:107572:13  at View.engine (D:\Projects\angular-habr-nestjs\node_modules\@nestjs\ng-universal\dist\utils\setup-universal.utils.js:30:11)  at View.render (D:\Projects\angular-habr-nestjs\node_modules\express\lib\view.js:135:8)  at tryRender (D:\Projects\angular-habr-nestjs\node_modules\express\lib\application.js:640:10)  at Function.render (D:\Projects\angular-habr-nestjs\node_modules\express\lib\application.js:592:3)  at ServerResponse.render (D:\Projects\angular-habr-nestjs\node_modules\express\lib\response.js:1012:7)  at D:\Projects\angular-habr-nestjs\node_modules\@nestjs\ng-universal\dist\angular-universal.module.js:60:66  at Layer.handle [as handle_request] (D:\Projects\angular-habr-nestjs\node_modules\express\lib\router\layer.js:95:5)  at next (D:\Projects\angular-habr-nestjs\node_modules\express\lib\router\route.js:137:13)

Чтобы решить косяк, зайдем в файл server/app.module.ts и поменяем значение liveReload на false:


import { Module } from '@nestjs/common';import { AngularUniversalModule } from '@nestjs/ng-universal';import { join } from 'path';@Module({ imports: [  AngularUniversalModule.forRoot({   viewsPath: join(process.cwd(), 'dist/browser'),   bundle: require('../server/main'),   liveReload: false  }) ]})export class ApplicationModule {}

Также подтюним конфиг тайпскрипта, так-как эта конфигурация не взлетает с использованием Ivy рендера:


// tsconfig.server.json{ "extends": "./tsconfig.app.json", "compilerOptions": {  "outDir": "./out-tsc/server",  "target": "es2016",  "types": [   "node"  ] }, "files": [  "src/main.server.ts" ], "angularCompilerOptions": {  "enableIvy": false, // Добавили флажок  "entryModule": "./src/app/app.server.module#AppServerModule" }}

После пересоберем приложение командой ng run serve чтобы SSR заработал.


Angular SSR + NestJS


Ура! SSR подрубился, но как видимо в devtools он приходит с кривыми стилями.


Добавим extractCss: true, который позволит выносить стили не в styles.js, а в styles.css:


// angular.json..."architect": {    "build": {     "builder": "@angular-devkit/build-angular:browser",     "options": {      "outputPath": "dist/browser",      "index": "src/index.html",      "main": "src/main.ts",      "polyfills": "src/polyfills.ts",      "tsConfig": "tsconfig.app.json",      "aot": true,      "assets": [       "src/favicon.ico",       "src/assets",       {        "glob": "**/*",        "input": "./node_modules/@ant-design/icons-angular/src/inline-svg/",        "output": "/assets/"       }      ],      "extractCss": true, // Добавили флажок      "styles": [       "./node_modules/ng-zorro-antd/ng-zorro-antd.min.css",       "src/styles.scss"      ],      "scripts": []     },...

Также подключим стили библиотеки в app.component.scss:


// app.component.scss@import "~ng-zorro-antd/ng-zorro-antd.min.css"; // Подключили стили:host { display: flex; text-rendering: optimizeLegibility; -webkit-font-smoothing: antialiased; -moz-osx-font-smoothing: grayscale;}.app-layout { height: 100vh;}...

Теперь стили подключены, SSR отдает страничку со стилями, но мы видим что сначала у нас грузится SSR, потом страница моргает и отрисовывается CSR (Client Side Rendering). Это решается следующим способом:


import { NgModule } from '@angular/core';import { Routes, RouterModule } from '@angular/router';const routes: Routes = [ { path: '', pathMatch: 'full', redirectTo: '/welcome' }, { path: 'welcome', loadChildren: () => import('./pages/welcome/welcome.module').then(m => m.WelcomeModule) }];@NgModule({ imports: [RouterModule.forRoot(routes, {initialNavigation: 'enabled', scrollPositionRestoration: 'enabled'})], // Добавили initialNavigation, scrollPositionRestoration exports: [RouterModule]})export class AppRoutingModule { }

  • initialNavigation: 'enabled' дает инструкцию роутингу не отрисовывать страницу, если уже загружена через SSR
  • scrollPositionRestoration: 'enabled' скролит страницу наверх при каждом роутинге.


3. Сделаем пару ендпоинтов на NestJS


Перейдем в папку server и создадим первый контроллер items:


cd servernest g module itemsnest g controller items --no-spec

// items.module.tsimport { Module } from '@nestjs/common';import { ItemsController } from './items.controller';@Module({ controllers: [ItemsController]})export class ItemsModule {}

// items.controller.tsimport { Controller } from '@nestjs/common';@Controller('items')export class ItemsController {}

Контроллер и модуль создались. Создадим метод на получение списка items и на добавление объекта в список:


// server/src/items/items.controller.tsimport { Body, Controller, Get, Post } from '@nestjs/common';class Item { name: string; age: number; address: string;}@Controller('items')export class ItemsController { // для простоты данные взял из Angular private items: Item[] = [  {name: 'Вася', age: 24, address: 'Москва'},  {name: 'Петя', age: 23, address: 'Лондон'},  {name: 'Миша', age: 21, address: 'Париж'},  {name: 'Вова', age: 23, address: 'Сидней'} ]; @Get() getAll(): Item[] {  return this.items; } @Post() create(@Body() newItem: Item): void {  this.items.push(newItem); }}

Попробуем вызвать GET в Postman:


GET запросы апишки NestJS


Отлично, работает! Обратите внимание, вызываем метод GET items с префиксом api, который ставится автоматически в файле server/main.ts при установке NestJS:


// server/main.tsimport { NestFactory } from '@nestjs/core';import { ApplicationModule } from './app.module';async function bootstrap() { const app = await NestFactory.create(ApplicationModule); app.setGlobalPrefix('api'); // Это префикс await app.listen(4200);}bootstrap();

Теперь прикрутим бэк к фронту. Возвращаемся к файлу welcome.component.ts и делаем запрос списка к бэку:


// welcome.component.tsimport { Component, OnInit } from '@angular/core';import { Observable, of } from 'rxjs';import { HttpClient } from '@angular/common/http';import { share } from 'rxjs/operators';@Component({ selector: 'app-welcome', templateUrl: './welcome.component.html', styleUrls: ['./welcome.component.scss']})export class WelcomeComponent implements OnInit { items$: Observable<Item[]> = this.getItems(); // прикрутили вызов бэка constructor(private http: HttpClient) { } ngOnInit() { } getItems(): Observable<Item[]> {  return this.http.get<Item[]>('/api/items').pipe(share()); }}interface Item { name: string; age: number; address: string;}

Можно увидеть что апиха на фронте дергается, но также дергается и в SSR, причем с ошибкой:


Дергание апихи в SSR


Ошибка при запросе в SSR решается следующим способом:


// welcome.component.tsimport { Component, OnInit } from '@angular/core';import { Observable, of } from 'rxjs';import { HttpClient } from '@angular/common/http';import { share } from 'rxjs/operators';@Component({ selector: 'app-welcome', templateUrl: './welcome.component.html', styleUrls: ['./welcome.component.scss']})export class WelcomeComponent implements OnInit { items$: Observable<Item[]> = this.getItems(); // прикрутили вызов бэка constructor(private http: HttpClient) { } ngOnInit() { } getItems(): Observable<Item[]> {  return this.http.get<Item[]>('http://localhost:4200/api/items').pipe(share()); // Прописали полный путь к апихе чтобы SSR не ругался }}interface Item { name: string; age: number; address: string;}

Чтобы исключить двойной запрос к апихе (один на SSR, другой на фронте), нужно проделать следующее:


  • Установим библиотеку @nguniversal/common:

npm i @nguniversal/common

  • В файле app/app.module.ts добавим модуль для запросов из SSR:

// app.module.tsimport { BrowserModule } from '@angular/platform-browser';import { NgModule } from '@angular/core';import { AppRoutingModule } from './app-routing.module';import { AppComponent } from './app.component';import { IconsProviderModule } from './icons-provider.module';import { NzLayoutModule } from 'ng-zorro-antd/layout';import { NzMenuModule } from 'ng-zorro-antd/menu';import { FormsModule } from '@angular/forms';import { HttpClientModule } from '@angular/common/http';import { BrowserAnimationsModule } from '@angular/platform-browser/animations';import { NZ_I18N } from 'ng-zorro-antd/i18n';import { ru_RU } from 'ng-zorro-antd/i18n';import { registerLocaleData } from '@angular/common';import ru from '@angular/common/locales/ru';import {TransferHttpCacheModule} from '@nguniversal/common';registerLocaleData(ru);@NgModule({ declarations: [  AppComponent ], imports: [  BrowserModule.withServerTransition({ appId: 'serverApp' }),  TransferHttpCacheModule, // Добавили  AppRoutingModule,  IconsProviderModule,  NzLayoutModule,  NzMenuModule,  FormsModule,  HttpClientModule,  BrowserAnimationsModule ], providers: [{ provide: NZ_I18N, useValue: ru_RU }], bootstrap: [AppComponent]})export class AppModule { }

Схожую операцию проделаем с app.server.module.ts:


// app.server.module.tsimport { NgModule } from '@angular/core';import { ServerModule, ServerTransferStateModule } from '@angular/platform-server';import { AppModule } from './app.module';import { AppComponent } from './app.component';@NgModule({ imports: [  AppModule,  ServerModule,  ServerTransferStateModule, // Добавили ], bootstrap: [AppComponent],})export class AppServerModule {}

Хорошо. Теперь получаем данные из апи в SSR, отрисовываем на форме, отдаем на фронт и тот не делает повторных запросов.


Запроса нет, данные есть!



4. Подключим базу PostgreSQL


Подключим библиотеки для работы с PostgreSQL, также будем использовать TypeORM для работы с базой:


npm i pg typeorm @nestjs/typeorm

Внимание: у вас уже должна быть установлена PostgreSQL с базой внутри.


Описываем конфиг подключения к базе в server/app.module.ts:


// server/app.module.tsimport { Module } from '@nestjs/common';import { AngularUniversalModule } from '@nestjs/ng-universal';import { join } from 'path';import { ItemsController } from './src/items/items.controller';import { TypeOrmModule } from '@nestjs/typeorm';@Module({ imports: [  AngularUniversalModule.forRoot({   viewsPath: join(process.cwd(), 'dist/browser'),   bundle: require('../server/main'),   liveReload: false  }),  TypeOrmModule.forRoot({ // Конфиг подключения к базе   type: 'postgres',   host: 'localhost',   port: 5432,   username: 'postgres',   password: 'admin',   database: 'postgres',   entities: ['dist/**/*.entity{.ts,.js}'],   synchronize: true  }) ], controllers: [ItemsController]})export class ApplicationModule {}

Немного про поля конфига:


  • type: указываем название типа базы данных, к которой подключаемся
  • host и port: место где база хостится
  • username и password: аккаунт для этой базы
  • database: название базы
  • entities: путь, откуда будем брать сущности для схемы нашей базы

По последнему пункту, нужно создать сущность Item для мапинга полей в базу:


// server/src/items/item.entity.tsimport { Column, CreateDateColumn, Entity, PrimaryGeneratedColumn } from 'typeorm/index';@Entity()export class ItemEntity { @PrimaryGeneratedColumn() id: number; @CreateDateColumn() createDate: string; @Column() name: string; @Column() age: number; @Column() address: string;}

Далее свяжем эту сущность с нашей базой.


// items.module.tsimport { Module } from '@nestjs/common';import { TypeOrmModule } from '@nestjs/typeorm';import { ItemEntity } from './item.entity';import { ItemsController } from './items.controller';@Module({ imports: [  TypeOrmModule.forFeature([ItemEntity]) // Подключаем фича-модуль и указываем сущности базы ], controllers: [ItemsController]})export class ItemsModule {}

Теперь укажем в контроллере, что хотим работать с базой, а не кешем:


// items.controller.tsimport { Body, Controller, Get, Post } from '@nestjs/common';import { ItemEntity } from './item.entity';import { InjectRepository } from '@nestjs/typeorm';import { Repository } from 'typeorm/index';interface Item { name: string; age: number; address: string;}@Controller('items')export class ItemsController { constructor(@InjectRepository(ItemEntity)       private readonly itemsRepository: Repository<ItemEntity>) { // Подключили репозиторий } @Get() getAll(): Promise<Item[]> {  return this.itemsRepository.find(); } @Post() create(@Body() newItem: Item): Promise<Item> {  const item = this.itemsRepository.create(newItem);  return this.itemsRepository.save(item); }}

Проверим работу апихи в Postman:


POST к апихе с базой


Работает. Потыкали несколько раз постман, посмотрим что записалось в базе с помощью DBeaver:


Записи в базе


Отлично! В базе есть, посмотрим как выглядит на фронте:


Рабочее fullstack приложение


Готово! Мы сделали fullstack приложение, с которым можно работать дальше.


P.S. Сразу поясню следующее:


  • Вместо Ng-Zorro вы можете использовать любую другую библиотеку, например Angular Material. Мне она лично не зашла из-за сложности разработки;
  • Я знаю, что нужно на бэке использовать сервисы, а не напрямую дергать базу в контроллерах. Эта статья о том, как решив проблемы "влоб" получить MVP с которым можно работать, а не про архитектуру и паттерны;
  • Вместо вписывания на фронте http://localhost:4200/api возможно лучше написать интерсептор и проверять откуда мы стучимся

Полезные ссылки:


Подробнее..

Психбольница в руках пациентов, или Инфраструктура как продукт

08.04.2021 16:21:10 | Автор: admin

У бизнес-разработчиков за дедлайнами, сроками, клиентами и большими запусками может складываться впечатление, что инфраструктура выстраивает свой воздушный замок, который далек от того, что происходит в действительности. Захотев это изменить, Алексей Данилов из разработки перешел в команду инфраструктуры последние два года он развивает ее в Яндекс.Вертикали а это Яндекс.Работа, Яндекс.Недвижимость, auto.ru и Яндекс.Объявления.

Особенность Яндекс.Вертикалей ребята одновременно и бизнес-юнит Яндекса, и обычная IT-компания. Благодаря первому, у них есть возможность использовать яндексовую инфраструктуру, но, благодаря второму, разработчики смотрят на весь стек и используют то, что им удобно. Алексей сегодня поделится с нами, как это можно сделать более удобно и ближе к пользователям (в его случае к разработчикам). А также о том, почему на инфраструктуру сейчас надо смотреть как на продукт и какие вызовы это приносит команде, но что это дает в конечном итоге компании.

Infrastructure

Под инфраструктурой я подразумеваю всё, что окружает бизнесовый код и помогает ему от начала разработки фичи до момента ее доставки. Это и базы данных, и балансировка, и мониторинг, и CI с CD. Сюда же относятся особенности разработки/работы, библиотеки, тестирование, бизнес аналитика, бизнес-специфичные возможности и много чего еще. Это как завод, на котором вместо ручного труда автоматизированы все процессы, и результат мы получаем более быстрый и более качественный.:

При этом я рассматриваю инфраструктуру как единую платформу, а не набор разрозненных частей, которые я перечислил выше. И это уместно для компании любого размера. В облаках Amazon Web Services, Yandex Cloud автоматизация может строиться, например, на основе terraform. У вас может быть собственное железо или вы его где-то арендуете и на нем может быть развернут Kubernetes, Nomad, что-то еще. Команда тоже может быть любой от нескольких человек, которые в основном используют bash или terraform, и до сотен, со своими велосипедами.

И тогда возникает вопрос как добиться идеальной инфраструктуры Platform as a Service, который мы реализуем для наших пользователей, и вообще каковы критерии идеальности? Нам не нужно разрабатывать еще один Amazon или Kubernetes поэтому достаточно небольшой и простой системы, но у нас должна быть возможность ее расширения под наши use cases. Например, если у нас есть какие-то особенные АБ-тесты, особенные условия доставки (например, канареечный релиз ) и особенные правила безопасности это как раз то, что должна закрывать инфраструктура.

Ее основой, краеугольным камнем будут минимизация/ускорение разработки, упрощение поддержки и простота использования. Остальные требования понятность, доступность, стабильность и единообразность/распространение практик, а также скрытие низкоуровневых особенностей (чтобы никому не пришлось писать самому конфиг nginx или сложный Kubernetes манифест), техническая поддержка 24*7 и связанность компонентов конечно, тоже имеют место.

Если выполнить их все, ваша инфраструктура будет не только единой платформой или сервисом, но постепенно будет превращаться в продукт, как это случилось у нас.

Infrastructure/Platform as a product (PaaP)

Сначала мы, конечно, смотрели в сторону сторонних приложений. Например, мы серьезно рассматривали Spinnaker от Netflix. Но он написан на Java, а у нас все пишут на Go, и мы не хотели добавлять еще один язык. Во-вторых, он не поддерживает Nomad и Yandex.Cloud. Следовательно, нам пришлось бы его прилично дорабатывать и интегрировать с нашими внутренними особенностями, что практически равно форку. Поэтому мы стали писать свое.

Изначально мы задумывали Shiva как абстракцию над деплоем (в нашем случае над Nomad) и как multicloud. Но сейчас она уже приросла различными системами и интегрируется со всем, что у нас внутри есть:

Основная ее часть представлена в GitHub в виде карты сервисов. Она изменяется посредством пул-реквестов, конфигурирует балансировку, контролирует деплой и различные пайплайны доставки, SOX, PCI DSS и т.д. То есть это одно описание для полноценной работы:

Архитектура Shiva в упрощенном виде выглядит так:

Сервис постоянно развивается и сейчас он уже частично похож на продуктовый: есть БД, вокруг которой построены различные микро-сервисы, есть небольшие legacy-компоненты (компонент Updater и Shiva смотрят в одну базу) и т.д. То есть с технической точки зрения он развивается как обычный бизнесовый сервис.

UI мы реализовали в Telegram, а впоследствии написали WEBовский. Telegram-бот это CLI over Telegram все команды задаются в формате CLI, но дополнены различными контекстными действиями, кнопками и т.д. Нам нравится этот подход, потому что он кросс-платформенный, его легко обновлять и к нему всегда есть доступ. Можно спокойно обновить или откатить свой сервис в случае проблем. А также очень удобный механизм нотификации, когда вы получаете уведомление о начале процесса деплоя прямо в тележку.

И хоть WEB и получился удобным, все равно часть пользователей остается в Telegram. Потому что UX меняется в профессию приходит очень много молодых разработчиков. Мы привыкли к WEB, мы привыкли использовать Telegram-боты и вообще общаться в чате. С другой стороны, мы хоть и думаем сделать CLI с такой же функциональностью, но понимаем, что запросов на это не было.

Экономика

Когда встал вопрос об экономике, то первое, о чем мы подумали модная сейчас юнит-экономика: ее используют при создании стартапа, чтобы понять, насколько он экономически выгоден. К тому же это очень удобный фреймворк:

Но у инфраструктуры нет доходов, тогда как на этой схеме есть и доходы, и расходы. Доход от инфраструктуры равен 0 это расход компании, а ROI будет отрицательным: сколько инвестиций не вкладывай, они не отбиваются:

Profit = Revenue - Cost = 0 - X

Есть, конечно, плюшки в виде, например, бесконечного LTV (LifeTime Value) то есть наши клиенты от нас никогда не уйдут. Но в целом эта метрика нам не подходила, и мы стали думать в сторону velocity (скорость разработки), потому что ее довольно легко преобразовать в деньги. Например, если мы ускорили разработку на час в неделю, то это нетрудно соотнести со средней зарплатой у 500 разработчиков и получить какой-то видимый профит. Вообще инфраструктура это именно velocity, то есть скорость доставки ценности пользователю. Но у нас это не глобальная метрика, потому что velocity зависит от очень многих факторов. : Если смотреть сверху, то можно выделить:

  • code время написания самой логики ;

  • infrastructure code время написания инфраструктурного кода (код логов, метрик, алертов и т.д.)

  • environments время на настройку переменных окружения, секретов и т.д.;

  • delivery время, затраченное на доставку.

На последние три пункта инфраструктура влияет напрямую и может существенно упростить или ускорить их. Для примера рассмотрим механизм проверки новой конфигурации для сервиса. Сначала наша карта сервисов проверялась небольшим скриптом, и далее ее уже должен быть допроверить человек. Но там, где есть работа реального человека, Velocity стремится в 0, а скорость разработки сильно снижается. Поэтому, если у вас деплой или изменение конфигурации (базовые повседневные вещи) завязаны на тикеты или другие инструменты, где есть влияние ожидание работы человека это те точки роста, которые нужно сразу же автоматизировать.

В нашем случае мы написали GitHub-бота, который с очень большим спектром валидации проверял эту карту и мгновенно отвечал: либо всё хорошо, либо есть какие-то конфликты с другими картами и сервисами:

Следующим нашим пунктом разработки инфраструктуры как продукта стало внедрение user story.

User story

User story это фундамент любой продуктовой разработки и используется он в любых гибких методологиях идущих от Agile. Это не детальное описание задач давайте прикрутим здесь кнопку, которая будет делать вот это. User story это намерение пользователя: какую проблему пользователь решал, как он пытался её решать, почему он её решал, почему она возникла, и, наконец, как мы можем её решить. Разумеется, из user story выводится очень много различных решений. Но сам User story не является им это основа для решения и инструмент для выявления исходной проблемы.

В бизнесовой разработке user story пишется на повседневном и понятном пользователю языке. Для нас здесь была небольшая ловушка, потому что наши пользователи разработчики, они очень грамотные и могут принести любую историю вплоть до того, что надо внести изменения в БД. Поэтому мы должны были обязательно вытягивать основную проблематику находить инкремент ценной функциональности, реализуемой за короткий срок.

Приведу для примера две наши внутренние истории.

Пример 1. Залипает обработчик Кафки. Чинится только рестартом сервиса. Фикс в пути. Хочется иметь способ быстро перезапустить контейнеры.

Проблема была понятной и мы предложили сделать команду restart -l prod my_service, в которой указывается слой сервис, чтобы сервис рестартился через телеграм бота.

Пример 2. При обновлении конфигурации хочется перезапустить сервис без указания версии.

Решением стало: /run -l prod -v 1.0.7 my_service -> /run -l prod my_service.

Но изначально это выглядело как одна задача: сделайте нам такую команду для рестарта, после которого сервис притягивает новую конфигурацию. С точки зрения обычной таски это можно было сделать, а с точки зрения user story нельзя, потому что в первом примере люди видят проблему и периодически рестартят свой сервер, пытаясь найти, что же здесь не так. Если при этом приедет новая конфигурация, это принесет им куда больше проблем, то есть мы можем сделать хуже.

Поэтому первое, что мы сделали это идемпотентный рестарт, который ничего не подтягивал и при этом гарантировал, что конфигурация будет идентична. А вторым стал run, который можно указать без версии версии и он подтянет новую конфигурацию (новые переменные окружения, новые секреты и обновит остальное окружение). Более того, когда мы в дальнейшем их разделили, то user story с запуском из версии модифицировали и развили так, что run стал гарантировать изменение сервиса. А если ему нечего изменять и нечего подтягивать, то он об этом честно говорил.

То есть разделяя user story, мы можем их по фидбэку развивать дальше. Но даже просто использование user story дает огромный профит, так как мы начинаем слышать пользователя о его проблеме. Но если общаться с пользователями и вместе находить решение не каждая user story будет реализована, и не каждая так, как мы придумали.

Customer development (сustdev)

Инструмент сложный в продуктовой разработке, но в случае инфраструктуры он очень прост потому что мы разрабатываем новый продукт (фичу, решение или какую-то часть нашей системы) не сразу через код, а через пользователя. Можно даже провести ниндзя-сustdev, находясь в переговорке в ожидании какой-нибудь встречи или попивая кофеечек на кофе-поинт. Да и сам процесс не очень сложный:

  1. Выявляем потенциальную проблему (строим гипотезу), формируем идею или решение, но не внедряем ее, а идем к пользователям, чтобы поговорить с ними об их потребностях/болях/проблемах.

  2. Встречаемся с ними, например, на кофе-поинте или на рабочем месте. Можно пообщаться и в Зуме. И в обсуждении можно обнаружить, что проблема пользователям не важна она не так много времени занимает и не так сильно его напрягает, но зато у него есть более важные проблемы.

  3. Прорабатывая решение вместе, мы получаем либо изначальное успешное решение (если определили проблему верно) или более успешное (поняв из общения, что волнует пользователей) то есть в выигрыше все.

Например, у нас не было истории деплоев, и мы понимали, что нам она нужна. Мы напридумывали очень много сложных вещей, вплоть до того, чтобы в Telegram с помощью пейджинга показывать список последних 10 сервисов и уже думали, как же их спейджить туда-обратно и т.д. Но пообщавшись с разработчиками, мы поняли, как история начинается у большинства из них: они видят на графиках аномалию и м нужно посмотреть, не было ли деплоя не новая ли версия принесла эту аномалию?

Эта история решилась довольно просто. Мы добавили время деплоя в аннотации на Grafana, и теперь видя какую-то аномалию, можно понять, не было ли деплоя, в том числе деплоя зависимых сервисов. Эта история, кстати, ускорила у нас создание WEB UI.

А потом мы пообщались с тимлидами и выяснили, что они это видят совсем по-другому:

Developer: Я вижу по графикам проблемы нужно проверить, не связано ли это с выкаткой новой версии (см. график выше).

Team leads: Нужна возможность посмотреть кто, что, когда и зачем катил в прод:

Для тимлидов эту историю со списком, сложными фильтрами, поиском и т.д. мы реализовали намного позже. Потому что, во-первых, наш основной пользователь это обычный разработчик тот человек, который каждый день пишет код, делает фичи, раскатывает их, дежурит, заботится о сервисе и т.д. А во-вторых, это был уже этап, когда мы начали выделять и использовать портреты пользователя, а затем и портреты сервисов.

Портреты пользователей и сервисов

И то, и другое сложно реализуется в продукте, но легко и быстро в инфраструктуре. Портреты пользователей у нас были довольно простыми:

  • Разработчики: бэкенд, фронтенд и инфраструктура;

  • Team leads;

  • Тестировщики/Автотестировщики;

  • Аналитики;

  • Менеджеры, продукты, руководители.

По сути частичное отражение рабочих позиций :)

А портреты сервисов можно классифицировать по типу, языку или размеру. Первые бывают внутренними (realtime api, back api, async, cron, gateway, и т.д.), DB, внешними, saas и т.д. И они богатая точка роста, потому что это место отказа каких-то инфраструктурных частей. Это и наша точка роста, которую мы рассматриваем в будущем для себя.

Языки разработки мы рассматриваем нечасто, но иногда приходится смотреть: почему эта история возникает, у кого она возникает, потому что, например, у java и node.js бывают небольшие различия в работе, и это приходится учитывать.

По размеру портреты сервисов могут быть: function, microservice, service, monolith, distributed monolith и т.д. И если мы, например, понимаем, что проблематика идет из распределенного монолита, то отказываем в этой истории, потому что у нас хорошей практикой считаются мироксервисы и нашим PaaS мы популяризируем и упрощаем жизнь именно с ними..

Вот для примера портрет сервиса БД. С помощью этой карты ставятся бэкапы, происходит доступ к БД на чтение/запись и т.д. Плюс, сам сервис в свои зависимости прочерчивает эту карту, и мы знаем, что это за карта и от чего она зависит то есть, мы знаем, что сервис А зависит от базы данных В:

Feature request

Но одно дело найти проблему. Совершенно другое когда приносят уже готовое решение. Это самая богатая тема, которую можно использовать себе на благо.

Конечно, у нас есть проблемы:

  • Технически грамотный пользователь может принести уже готовое решение, например: Сделайте такой API, в БД все сохраните, и на этом хватит.

  • Личное знакомство потому что иногда мы отказываем в feature request или говорим, что будем делать по-другому, и возникает небольшой конфликт.

Но есть и решения:

  • Превращать в user story находить проблематику: узнавать, с какой проблемой столкнулся пользователь и как пытался решать;

  • Смотреть на доработку в контексте портретов кто к нам пришел, что за сервис, о чем идет речь;

  • Спорную доработку или ту, в которой мы не уверены, проверять через castdev, потому что все-таки feature request приносит один пользователь и непонятно, насколько это ценный функционал для всех;

  • Механизм голосований/рейтинга это самый мощный инструмент. Он не нов, используется во всех хороших продуктовых разработках, например, в терминале Тинькофф-Инвестиции. У них открытые feature request, где люди открыто голосуют и в итоге в работу идут те, что в топе:

Внутри это также можно легко реализовать, потому что мы работаем в рамках одного issue-трекера. Например, здесь фильтры по нашим feature request:

Из интересного: мы недавно этот вид сделали через наш WEB не таким формальным и увидели, что люди с большей охотой голосуют за идеи то есть это тоже важно:

Механизм feature request очень удобно использовать как часть синергии с пользователем и нам не нужно будет сильно прорабатывать такую историю ведь очень много пользователей проголосовали за нее. Мы можем видеть, кто голосует и это могут быть разные люди, которые поддерживают разные сервисы. Получается в итоге даже небольшой scoring функциональности мы точно понимаем и то, что она нужна, и зачем, и насколько это нужно пользователям. Голосование к тому же может заменить множество внутренних исследований таких, как сustdev.

Roadmap

Хочу отдельно сказать про Roadmap. Это кажется довольно банальной темой, но пообщавшись с разными компаниями, я обнаружил, что у команды инфраструктуры часто не бывает долгосрочного видения. Есть понимание, что они делают через неделю или месяц, но нет понимания, какой должна быть в итоге инфраструктура. И обычно это инфраструктура посредством одной кнопки, когда все описано в GitHub-репозитории и сделана она, например, на CI сборках. Куда стремиться непонятно.

Ценность даже не в самом плане, а в процессе планирования. Когда мы планируем, мы думаем, что хотим дать пользователям, поэтому roadmap удобно сделать открытым можно сразу получить фидбэк. Мы можем расставить истории по приоритетам, фидбэк может сказать нам, что большинству намного важнее то, что мы отложили. Так что публичные и регулярно обновляемые планы помогут вам скорректировать roadmap и строить долгосрочный бэклог на его основе.

Кстати, как получать обратную связь?

  • Тикеты и подписки на них. В нашем случае это самый рабочий инструмент, потому что мы работаем в одной компании, и в одном трекере.

  • Большие посты анонсы. Несколько раз в квартал мы делаем большие анонсы, где рассказываем про всю большую функциональность и опять же получаем фидбэк. Иногда мы получаем негативные отзывы, например: Зачем вы это делаете, если можно взять вот это и то. Тогда мы либо объясняем, либо понимаем, что, может и правда можно реализовать более просто.

  • У нас есть групповой чатик в Telegram/Slack/Microsoft Teams. В основном мы там собираем обратную связь, хотя он работает как инструмент технической поддержки, а также в нем выкатываем нововведения с небольшими инкрементальными релизами.

  • Открытые встречи для вопросов/ответов. Мы пока что провели её только один раз, но результат был неплохой.

  • Еще можно встречаться на демо продуктовой разработки и там отвечать на вопросы. Но мы не проводим демо сейчас для нас это большая потеря времени.

  • Еще можно использовать индекс потребительской лояльности NPS (Net Promoter Score). Это простые анкеты: насколько вы удовлетворены нашим сервисом, насколько вам удобно базовые вопросы для того, чтобы собрать общую статистику лояльности пользователей. Мы не используем NPS, потому что из чата получаем и критику, и позитив, а остальных записываем как нейтральных пользователей.

MVP

После планирования хочу напомнить про инструмент MVP (Minimum Viable Product). Это известный подход, но в инфраструктуре есть нюансы. Мы, как любой бизнесовый продукт, выкатываем частично недоделанный продукт, где-то не самый удобный, но минимально рабочий. Потому что мы не можем делать 2-3 месяца какую-то историю, выкатить её, получить средний фидбэк и потом еще месяц переделывать:

Henrik KnibergHenrik Kniberg

Поэтому мы стараемся поддерживать максимально инкрементальные релизы для того, чтобы потихонечку двигаться к тому функционалу, который запланировали в будущем и который, опять же, всем известен. А получая фидбэк, мы успеваем его корректировать:

Henrik KnibergHenrik Kniberg

Например, когда мы резолвили свой первый WEB, его функциональность была далека от функциональности Telegram, да и выглядел он неказисто, если честно. Но впоследствии он развивался, мы получали фидбэк, и в результате даже пошли по другому пути, потому что UXe (пользовательский опыт) отличается от того, что было в Telegram, и от того, что есть в WEB.

WEB сейчас поддерживает тот же самый функционал, но он в той или иной мере реализован в WEB немного по-разному. Плюс, он расширился: в нем есть истории деплоев, работа с картой и манифестом, с переменными окружения и т.д.

Overkill

Важно понимать, когда продуктовый подход становится слишком сложным. Бизнесовые команды становятся настолько большими, что состоят из множества людей с разной направленностью и спецификой. Есть product owner, цель и задачи которого выстраивать roadmap и определять, какие из историй делаются. Есть product менеджер, UX-специалисты, разработчики, тестировщики и т.д. Когда большие истории разбиваются только по user story и пытаются делать с добавлением какой-то пользовательской ценности. Всё это очень круто, но сейчас для нашей команды это overkill. Как в принципе, и A/B-тестирование.

Поэтому нужно четко определять, что мы используем, а что нет. Для небольших команд инфраструктуры, как наша, есть лайфхаки, которые помогают иметь результат не хуже:

  • Стараться понять: Зачем? То есть не Разработчик хочет 500 Тб БД, а: Разработчику нужно сохранять информацию о машинках (которую мы никогда не сохраняли) тогда мы сможем работать вместе над одной проблемой пользователя

  • Добавить в команду продуктового разработчика, потому что DevOps расширяется, кода мы пишем сейчас больше, и нужен разработчик, который пропитан этой атмосферой.

  • Добавить в команду фронтендера, понимающего в той или иной мере в интерфейсах. Да, это не профессиональный дизайнер, но для инфраструктуры этого достаточно.

  • Обязательно нужен механизм голосования за идеи для того, чтобы упростить scoring задач.

  • Собирать roadmap и сделать его открытым.

  • Периодически собирать аналитику не сложные и большие графики, но чтобы плюс-минус понимать, что происходит у пользователей.

  • Нужно много автотестов , так как я все еще не представляю вакансии тестировщика в команде инфраструктуры, как и дизайнера по крайней мере в 2021 году.

  • И основной пойнт больше синергии с пользователями. Потому что хорошую инфраструктуру ограниченной командой с ограниченными ресурсами можно делать только в синергии с пользователями вытаскивая самые ценные истории.

Итог

В заключении рекомендую книгу Психбольница в руках пациентов Алана Купера я ее прочитал очень давно и с огромным удовольствием, она меня вдохновила. Сейчас настало время, когда ее стоит рекомендовать не только product owner, продуктовым разработчикам, дизайнерам, но и команде инфраструктуры. Там очень много полезных примеров, в которых можно найти себя.

Подытоживая:

  • Разговаривайте со своими пользователями, находите проблематику надо искать проблемы, а не решения.

  • Относитесь к внутренней инфраструктуре как к единой платформе, как к единому PaaS.

  • Разрабатывайте PaaS как полноценный внутренний продукт.

  • Используйте проверенные простые продуктовые подходы, но только те, которые окажутся простыми. Если тот или иной подход (тот же сustdev или портреты пользователей) кажется сложным, возможно, сейчас их не стоит использовать.

  • Повышайте ценность PaaS (скорость/расходы разработки/поддержки).

  • Создавайте современные интерфейсы.

  • Примите, что современная команда инфраструктуры приближается к продуктовой. Её уже официально называют командой DevOpsеров. Эта мифологическая команда приближается к продуктовой по своим требованиям и тому, как она должна работать. Следование новым веяниям и использование современных подходов поможет создавать действительно удобную инфраструктуру

А любые сложности можно обойти в синергии с пользователем. Если вы создадите коммуникации и инструменты для этого, вы получите максимум фидбэка, а значит максимум информации, как инфраструктура может сделать компанию эффективней. Пишите, я готов к обсуждению.

Профессиональная конференция DevOpsConf 2021 пройдёт 31 мая и 1 июня этого года в Москве, в отеле Radisson Slavyanskaya. Расписание уже сформировано. На сайте вы можете познакомиться с программой и спикерами.

Как всегда, будут реальные кейсы компаний, сложные инженерные аспекты цифровой трансформации, многообразие технологий и подходов: наглядно, просто, с конкретными рекомендациями. Билеты здесь.

До встречи в оффлайне!

Подробнее..

Software Engineer Product Manager Product Engineer?

06.01.2021 16:04:08 | Автор: admin

TL;DR

В этой статье попробуем разобраться нужно ли инженеру продуктовое мышление (и в каких случаях), какие плюсы (и минусы) это даёт, и возможно ли совместить в одном человеке два разных (часто противоречащих) образа мышления. Ведь разные образы мышления ведут в разным приоритетам, а как следствие и разным действиям.

Intro

Привет! Меня зовут Ил. И я работаю в стартапе. Нас около 20 человек половина команды (русскоязычная) занимается технологиями, вторая половина (англоязычная) занимается бизнесом. Официальный язык общения английский. Мы (как продукт, бизнес и команда) быстро растём, итерируемся, меняемся и развиваемся. Поэтому для нас критически важно чтобы было отличное взаимопонимание между бизнесом и технологиями. Обычно в компаниях эту функцию выполняют продуктовые менеджеры или аналитики. И у нас они тоже есть. Даже двое. Но каждый из них работает над продуктовыми задачами только 50% времени, совмещая эту роль с другими ролями. Поэтому суммируя, можно сказать что у нас в команде один Product Manager. А скорость изменений такая, что в полной мере формализовать, описать и декомпозировать задачи у PM-команды времени физически не хватает. Поэтому большинство задач у нас описываются достаточно высокоуровнево с акцентом на что хотим получить после того как задача будет выполнена. Процесс декомпозиции задачи, поиск возможных путей решения, выбор оптимального способа и более детальная проработка задачи (в том числе с точки зрения требований и продукта) обычно делегируется инженерам.

Погружаемся

Я бльшую часть времени занимаюсь бэкендом, но как часто бывает в стартапах по факту занимаюсь очень разными задачами. Несколько примеров задач из реальной жизни (которые инженеры обычно не решают):

  • Сделать research по barcodes (штрих-коды на товарах). Понять какие для них есть международные стандарты, как они различаются в раличных странах, какой у них формат, как их валидировать и прочее;

  • Создать план тестирования и/или миграции для большой фичи меняющей поведение в критически важном месте системы;

  • Спроектировать новую архитектуру для критической части системы на основе опыта и ошибок первой версии. Сюда входит в том числе проработка и формализация новых требований, поиск того что нужно изменить в бизнес-процессах, проектирование сценариев работы и т.д.;

  • Поискать готовые 3rd party решения для той или иной задачи и оценить что в данный момент эффектнее взять один из них или написать самим.

В какой-то момент я внезапно осознал, что непосредственно инженерными задачами я занимаюсь не более 50-60% времени. А иногда и того меньше. Вторая половина моего времени уходит на другие активности:

  • звонки, обсуждения, обмен знаниями о продукте;

  • интервью кандидатов, участие в hiring-процессах;

  • изучение PRD (по русски ТЗ), поиск в нём "багов" заложенных ещё на уровне описания идеи и логики, выявление слабых мест, поиск мест которые можно сделать лучше, проще или оптимальнее, оценка времени необходимого на разработку;

  • эксперименты, проверка гипотез (продуктовых), POCи (proof-of-concepts);

  • написание спецификаций, инструкций и других документов для фрилансеров (часть задач мы аутсорсим) и коллег;

  • координация с другими командами и членами команд;

  • выявление слабых мест в процессах, и улучшение процессов;

  • поиск готовых решений для не mission critical задач (чтобы не изобретать велосипед) и анализ как прагматичнее поступить в конкретном случае запилить своё решение или взять готовое;

  • smoke-тестирование;

  • работа с продуктовыми метриками в Amplitude;

  • генерация кастомных отчётов.

Ещё один важный момент. Когда мы обсуждаем новую фичу (либо для фичи уже есть PRD, и мы делаем техническое ревью) требования почти всегда очень туманные, и бизнес команда смутно понимает чего хочет. Поэтому существенная часть времени уходит на то чтобы:

  • понять чего хочет бизнес;

  • понять чего хочет бизнес на самом деле (обычно 20-50% требований меняется в процессе обсуждения, ещё до начала реализации);

  • уточнить неочевидные детали, краевые случаи;

  • проанализировать и найти оптимальное техническое решение.

При этом крайне желательно донести до всей команды особенности выбранного в итоге решения, в том числе его ограничения и недостатки. Потому что выбранный вариант решения задачи это почти всегда trade off (причём достаточно жёсткий): между скоростью разработки, качеством, масштабируемостью и расширяемостью.

Все перечисленные факторы приводят к тому что становится критически важно мыслить не только инженерными ценностями (должно работать быстро, стабильно, безопасно) но и продуктовыми (с вероятностью 80% через несколько месяцев мы удалим этот код или полностью его перепишем). Если не подходить в ежедневной работе с подобной точки зрения, удовлетворённость от работы очень сильно снижается.

Ещё одна важная культурная деталь нашей команды достаточно плоская структура и то, что каждый инженер лично отвечает за свою задачу, от момента её придумывания до user adoption. И написание кода это лишь один из этапов. Лично отвечает не значит что если что-то пойдёт не так, то человека уволят или лишат премии. Нет. Это значит что нужно будет вернуться назад и переделать. И прагматичное, рациональное, продуктовое мышления уменьшает кол-во таких итераций-переделок кардинально.

+/-

У такого режима работы определённо есть как плюсы, так и минусы. Попробуем в них разобраться.

Разберём плюсы. Почему это круто:

  1. Ты намного лучше понимаешь приоритеты, чётко знаешь что важно, а что второстепенно (в мире стартапов "второстепенно" и "не важно" по сути синонимы). Следовательно, понимаешь каким частям кода следует уделять больше внимание, а в каких в данный момент можно на*****кодить

  2. Ты начнёшь понимать мотивы продуктовых решений, почему решили сделать так, а не иначе. Соответственно ты будешь в курсе дальнейших планов на проект/фичу. Это поможет выстроить более адекватную архитектуру

  3. Тебе будут чаще давать более глубокие, сложные, интересные задачи. Ты получишь больше свободы. И больше ответсвенности

  4. Это интересно. Понимать продуктовые метрики и особенности поведения пользователей это увлекательно. И это затягивает

  5. Когда начнёшь думать не только о коде, но и о продукте, у тебя постепенно начнёт меняться мышление. Ты заметишь, что тебе станет проще коммуницировать с коллегами, которые занимаются продуктовым менеджментом, проектным менеджментом, аналитикой. Тебе будет проще их понимать. А им тебя. Работа станет менее стрессовой и более продуктивной

  6. Качество твоих фич и решений будет увеличиваться. Как следствие, качество всего продукта тоже будет расти. Вместе с продуктом, твоя ценность в команде тоже будет становится всё больше

  7. Тебе откроются новые возможности это может стать первым шагом к своему стартапу, или крутой карьере в FAANG, или повышению на текущем месте, или удачному exit-у (если у тебя есть опционы)

Почему это не круто:

  1. Частые смены контекста вредят здоровью. Они не только значительно повышают уровень стресса, но и могут пагубно влиять на мозг. Многочисленные исследования подтверждают это злоупотребление многозадачностью может привести в снижению общего IQ и негативным изменениям в мозге на физическом уровне, таким как уменьшение плотности нейронов (1, 2). А тебе придётся менять контекст очень часто. Твои дни станут более рваными. Ты будешь заниматься несколькими задачами одновременно и минимум 10/20/30 разными задачами в течении дня. Ты скорее всего станешь более нервным и раздражительным. У тебя могут начаться головные боли, даже если раньше ты был им не подвержен

  2. Тебе придётся делать то, что раньше ты скорее всего никогда не делал, потому что это делали за тебя твои коллеги. Например: работать с системами продуктовой аналитики, системами для рекламы, маркетинга, сервисами для мокапов, прототипирования, дизайна. Тебе придётся разбираться с множеством смежных областей и инструментов в этих областаях. Быть проактивным. Пушить других людей, если они не реагируют вовремя (в том числе твоих менеджеров). Назначать встречи/звонки. И это не вместо кодинга, а вместе с кодингом

  3. Ты начнёшь замечать конфликты в своём мышлении, а возможно и в решениях. За хорошее решение принятое тобой как инженером, твой внутренний PM может на тебя косо посмотреть или даже обидеться (привет, биполярочка!)

  4. Определённости и чётких ответов в твоей жизни станет ещё меньше, чем сейчас

Интегрируем

Вот мы и подходим к тому, с чего начали в заголовке статьи.

Термин Product Engineer пока ещё не очень популярен, но я думаю что в скором времени его популярность будет расти. Возможно для этой роли придумают другие названия, но суть не поменяется.

Драйверов развития этой роли несколько:

  1. Новым IT-компаниям становится сложнее найти своё место на рынке, юникорны появляются всё реже. При этом зарплаты инженеров продолжают расти, как и общие затраты на команды. Ведь с насыщением и усложнением индустрии растёт и количество человеко-часов которые нужно инвестировать чтобы построить успешную высокотехнологичную компанию. В таких условиях продуктовые инженеры могут оказаться редкими покемонами, которых хочет к себе в команду любой стартап. Ведь один человек способен закрыть сразу две позиции (а как бонус ещё и меньше overheadа на коммуникацию)

  2. Сейчас наблюдается бум продакт менеджеров. Появилось много курсов на которых их обучают, некоторые из них дают реально очень качественные знания. В продакт менеджеры переходят из смежных сфер (разработка, дизайн, тестирование, аналитика) и из совсем других сфер. Это говорит о том, что в целом в индустрии есть постоянно растущий спрос на людей способных создавать и развивать продукты.

В таких условиях, с учётом того что продуктовый менеджмент будет усложняться, вполне гармонично может появиться новая роль на стыке между инженерами и менеджерами продуктовый инженер. Примеров появления новых профессий на стыке двух других уже было очень много:

  • Сисадмин/программист DevOps;

  • Программист/бизнесмен Product Manager;

  • Рекламщик/веб-мастер SEO-шник.

Достаточно отважен и хабр храбр?

Успей запрыгнуть в поезд! Но помни тормозов у этого поезда, похоже, нет.

Подробнее..

Из песочницы Почему MVP вашего продукта может привести к краху идеи? Или как тестировать продукт на сформированном рынке

03.11.2020 12:06:29 | Автор: admin
MVP(Minimum Viable Product) или Минимально Жизнеспособный Продукт достаточно популярный термин среди стартапов. Но мало кто знает, что даже успешный MVP может потерпеть крах, поскольку не только качество MVP влияет на успешность проекта, но и ряд других факторов.

Часто стартапы путают термин MVP с прототипом продукта, но, к сожалению, прототип нельзя продать. MVP должен быть уже рабочим продуктом, за который ваша ЦА готова заплатить.

Успешные примеры использования MVP


Spotify


image

Создатели проекта изначально разработали приложение с единственным функционалом потоковая передача музыки. Благодаря большому кол-ву пользователей, команда смогла подписать контракты с крупными лейблами и получить финансирование. Сейчас Spotify оценивается в $26.5 млрд.

Wildberries


image

Татьяна Бакальчук, основательница маркетплейса, начала с закупки женской одежды, затем создала сайт и запустила рекламу своего интернет магазина на платформе Passions.ru, в первый же день получила несколько заказов. Непременно на начальном этапе развития были проблемы, но это совсем другая история. Сейчас Wildberries является самым крупным маркетплейсом в России с оборотом в 223.5 млрд рублей.
К сожалению не нашел фотографии первой версии маркетплейса.

Dropbox



Проверка жизнеспособности продукта это не обязательно готовый сервис. В случае с Dropbox всё началось с демо-видео, в котором всего за 3 минуты была представлена идея. При этом, самого продукта ещё не было. Видео получило положительные оценки, миллионы просмотров, тысячи комментариев, и помогло привлечь инвесторов.

Всех этих проекты объединяет то, что они запускали свой продукт на несформированном рынке, либо на рынке, где нет очевидного лидера. Но что если вы решили запустить таск-менеджер с новой фичей? Либо новый маркетплейс или мессенджер?

В случае, когда рынок сформирован, MVP не даст вам результата. Вы не можете выпустить продукт с базовым набором функционала.

Когда рынок устоявшийся и на нем уже присутствуют игроки, которые решают данную потребность, вы не можете выйти с тем же базовым продуктом. Для примера можно вспомнить проект Basecamp для работы с проектами: какой вау-эффект был во второй половине нулевых, а теперь это никому не интересно. Сейчас клиентам нужен продукт, которым можно пользоваться. Также, Павел Дуров, выпуская продукт Telegram, запустил быструю версию WhatsApp, со всеми базовыми функциями которые были на тот момент. Он не сделал user experience хуже, чем в современных мессенджерах, которым пользовались многие люди, а это уже не MVP. Данный метод работает во многих сферах бизнеса. Вы не можете запустить MVP и сказать Ребята используйте пока так, но мы скоро допилим продукт и он будет нормальным. Только ваши друзья могут потерпеть, а клиенты запомнят какой плохой продукт и вряд ли вернутся, чтобы протестировать его еще раз после полноценного запуска. Сейчас рынку нужна хотя бы бета-версия на небольшую аудитория, либо совсем небольшой продукт без лишних фич.

Успешные проекты, которые запустились без MVP, но добились успеха:


Beru


image

Маркетплейс Beru.ru не запускался поэтапно, его выпустили с уже имеющимся продуктами и полезными фичами. Также, сделали крутые маркетинговые акции. Что было бы если бы это был такой же проект, как Wildberries? Или же вообще, с таким же начальным функционалом, с которым начинал Wildberries? Я думаю, проект сразу закрылся бы.

Binance.com


image

Когда рынок криптовалют начал набирать стремительные обороты, появилась биржа под названием Binance со штаб-квартирой в Гонконге. Благодаря удобному функционалу и доступным инструментам, биржа быстро стала популярной. Спустя 7 месяцев, на платформе было зарегистрировано более 7.5 млн человек.

Но если бы биржа пошла по пути тестирования идеи и ее презентации (как это делали другие биржи), этот рынок мог бы занять другой игрок с более удобным и мощным функционалом.

Яндекс.Такси


image

Когда Яндекс запустил проект с собственным таксопарком, он разработал полноценный продукт, не хуже конкурентов, которые присутствовали на тот момент. Кроме базовых функций, он смог быстрее всех подавать автомобили и тем самым вытеснил с рынка других игроков.

Zoom


image

Основатель Zoom Эрик Юань ушел из компании WebEx, чтобы запустить собственный продукт, напрямую конкурирующий с вчерашним работодателем. Когда запускался Zoom, на рынке уже существовали такие игроки как Skype, Google Hangouts и другие. Главным драйвером роста для Zoom были привлекательные условия с заметно лучшим качеством связи. Когда остальные продавали видеоконференции за 30-70 долларов в месяц. Zoom предложил 40 минут бесплатного общения, либо безлимит всего за 15 долларов.

MonoBank


image

Мобильный банк, созданный бывшими топ менеджерами ПриватБанк. Когда ребята запускали Mono Bank, они по сути создали лучшую версию ПриватБанка. Главной фишкой нового банка стал кэшбек. На данный момент, банк имеет более 1.3 млн клиентов.

Подобных проектов, которые смогли предложить рынку лучшую услугу, чем доступные на рынке в тот момент, достаточно много. Поэтому, на уже сформированном рынке сложно разработать продукт с минимальными затратами, только чтобы проверить гипотезу.

Давайте рассмотрим примеры проектов, которые не смогли добиться успеха, так как их продукт проигрывал конкурентам по user experience.

Стартапы с хорошей идей, но с провальным MVP


Социальная сеть Аура


image

Когда Яндекс объявил о запуске социальной сети Аура, все побежали регистрироваться и тестировать продукт. Фишка социальной сети была в том что сервис автоматически подбирает собеседников и сообщества на основе предоставленной пользователем информации: увлечения, геолокация, лайки и т.п.

В первый месяц проект был достаточно популярным, но, со временем, люди перестали им пользоваться, т.к. социальная сеть работала только в официальном приложении от компании Яндекс. Социальная сеть не имела отдельного приложения и имела ряд проблем, которые усложняли взаимодействие с Аурой. По итогу, в августе 2020 года компания Яндекс объявила о закрытии социальной сети Аура.

Браузер Амиго


image

Интернет браузер Амиго от IT гиганта Mail.ru был запущен в 2011 году, но так и не добился успеха. Кроме того, что браузер не особо выделялся среди своих конкурентов, так он еще и заработал плохую репутацию за счет агрессивного маркетинга. Пользователи жаловались, что браузер устанавливается без их разрешения. Здесь та же история с user experience.

Мессенджер ICQ


image

Достаточно популярный мессенджер в начале нулевых со временем стал никому не нужным, т.к. на рынке появились конкуренты, которые предложили решение той же потребности с лучшим user experience и дополнительными фишками.

Flatora


image

Это российский аналог проекта Airbnb. Проект привлек порядка $750 000 в 2012 году, но закрылся уже в мае 2013 года. Причиной закрытия стал тот факт, что некоторые функции не работали: не было возможности проводить транзакции и ряд финансовых операций. Проект вышел на конкурентный рынок с сырым продуктом, который не смог дать пользователям сервис, решающий хотя бы те же потребности, которые решает Airbnb.

Travelmenu


image

Онлайн-турагентство Travelmenu получило инвестиции в размере $1.6 млн от фонда Almaz Capital и Runa Capital в мае 2011 года, но не смогло занять свою позицию на рынке и закрылось в апреле 2013. Основными конкурентами, на тот момент, были Anywayanyday и Booking.com. Главной причиной закрытия стало решение отложить выход на B2C рынок, вместо этого сервис начал с B2B.

Подводя итог, хочется обратить внимание новых стартапов, которые планируют выйти на сформированный рынок, что перед запуском бета версии следует убедиться, что ваш продукт, как минимум, имеет базовой функционал, покрывающий основные потребности рынка, и имеет свою уникальность особую фишку, за счет которой вы будете привлекать пользователей.

Всем желаю успехов и много денег.
Подробнее..

Почему управлять государством должен продуктовый менеджер?

21.01.2021 22:16:06 | Автор: admin

Потому что государство это продукт. Со своими метриками, экономикой, жизненным циклом. У граждан-пользователей есть и лайфтайм, и отток, и средний чек. Да и цели те же: найти свою нишу на мировом рынке, решить боли пользователей, повысить выручку и капитализацию. Только вот чиновники, которые управляют нашими странами, угробили бы любой стартап примерно сразу.

Рыба с головы портится

Что, если проблема человечества не в перенаселении или глобальном потеплении? Не в бедности, неравенстве и даже не в культуре потребления? Вдруг это всё только следствия?

Думаю, единственная настоящая проблема человечества невероятно хреновый менеджмент.

Если бы у руля стояли компетентные люди, то все проблемы решались бы последовательно и без особых драм. Мы бы вытаскивали самые приоритетные задачи из общечеловеческого бэклога. Фокусировали на них внимание ученых и экспертов. И щелкали их как семечки, одну за одной.

Вместо этого у нас типичная история про лебедя, рака и щуку как на уровне всего человечества, так и на уровне отдельных государств. Причем лебедь хочет в космос, рак в средневековье, а щука обеспокоена только сохранением собственной власти.

Феномен стартапов

Интересно, что хреновость менеджмента распределена неравномерно.

Мы наблюдаем тотальную некомпетентность руководства многих государств, но потрясающий профессионализм в успешных IT-стартапах.

Вероятно, причина в том, что государства могут выживать, будучи неэффективными. При обилии природных ресурсов, например. Или если держать население в нищете. А лучше и то, и другое вместе.

В то же время, стартапы подвержены такому быстрому и жесткому естественному отбору, что любая серьезная некомпетентность в управлении убивает их сразу же.

Именно этот контраст заставляет думать, что менеджеры стартапов управляли бы государством эффективнее чиновников. Тем более, что задачи у них схожие.

Самих депутатов вряд ли можно чему-то научить. И даже если выгнать их всех на мороз и набрать новых, условно компетентных нет гарантии, что всё это снова не превратится в бешеный принтер. Возможно, дело в самой системе: сотни высокооплачиваемых дилетантов сидят и жмякают кнопочки. И, главное, никто из них ни за что не отвечает.

Но и совсем без менеджеров не обойтись

Перед публикацией решил посмотреть а что вообще на Хабре есть про управление государством? К моему удивлению, нашлось немало идей про прямую демократию. Это когда каждый гражданин непосредственно участвует в принятии государственных решений.

Думаю, это провальная история. Как кораблю нужен капитан, так и продукту нужен product owner. Потому что большинство пользователей хочет пользоваться продуктом, а не работать над ним. Кроме того:

  • Пользователи часто не знают, что именно им нужно. И, тем более, не могут представить оптимальное решение. Они хотят пресловутую более быструю лошадь вместо автомобиля.

  • Хотелки разных пользователей могут противоречить друг другу и даже быть взаимоисключающими.

  • Пользователи не могут оценить стоимость, сложность и риски внедрения своих хотелок. Тем более оценить последствия в долгосрочной перспективе.

  • Большинство пользователей попросту недостаточно компетентно, чтобы принимать осознанные управленческие решения.

  • Наконец, люди легко ведутся на популизм и подвержены стадному инстинкту. Достаточно представить, что им предложили проголосовать за 10-кратное снижение налогов или повышение зарплат. Конечно, большинство эти инициативы с радостью поддержало бы. А в скором времени экономика государства загнулась бы.

Как же заставить всю эту государственную махину работать? Возможно, тут-то и пригодится опыт стартапов. А именно методологии, которые позволяют взвешенно принимать решения и предельно точно оценивать их результаты.

Давайте порассуждаем, какие IT-методологии было бы классно внедрить в управление государством.

Приоритезированный бэклог

Я открываю новостной Telegram-канал и вижу новые законы, один интереснее другого:

  • Депутаты переименовали улицы

  • Депутаты запретили аниме

  • Депутаты запретили критиковать власть

  • Депутаты увеличили штрафы для водителей

  • Депутаты запретили Telegram

То есть вместо системной работы над ключевыми метриками они пытаются лечить отдельные симптомы костылями да заплатками. Цитируя классику: What is going on inside their head?.

Кто-то скажет: Ну, это отдельные скоморохи всякую ерунду предлагают.

Нет.

Во-первых, это не просто предложения, это принятые законы. А значит, за них проголосовало большинство депутатов.

А во-вторых, невозможно представить, чтобы в профессиональной среде кто-то всерьез такое предлагал. Его бы сразу поставили в тупик простейшими вопросами:

  • Что будет считаться успехом и как ты измеришь результат?

  • Как, по-твоему, это будет внедряться и контролироваться?

  • Как это поможет решить ключевые проблемы государства?

Тот трэш, который мы наблюдаем, возможен только в среде насквозь некомпетентной.

Но, постойте, почему это кажется таким знакомым?

Потому что именно так действуют люди, которые берутся управлять продуктом не имея нужных навыков. Откройте любую статью на тему Как мы пять лет пилили продукт, а потом поняли, что он никому не нужен или Как мы годами делали фичи, а потом закончились деньги и мы так и не запустились там будут истории ровно тех же фэйлов.

Это типичная ошибка управления продуктом, когда люди мечутся между придумыванием новых фич и точечными правками. Я нередко вижу такие инициативы в тестовых заданиях джунов. Как правило, таких ребят мы даже на собеседование не зовем. Видимо, после этого они и идут в депутаты от безысходности, так сказать.

Поиск точки роста

Если продукт уже запущен и работает, то худшее, что можно сделать, это начать его хаотично улучшать. Бездумно добавлять фичи и законы, править дизайн и цены, менять логику и конституцию.

Что нужно на самом деле: проанализировать текущую бизнес-модель, юнит-экономику, воронки привлечения, активации, удержания. Найти узкое горлышко всей системы. Сфокусировать все усилия только на проблемных метриках. Нагенерить гипотез. Сложить их в бэклог и последовательно проверять.

Культура гипотез

Откуда берутся гипотезы в здоровом стартапе?

Продуктовый менеджер изучает аналитику и большие данные, проводит опросы и интервью пользователей, исследует удачные решения конкурентов, консультируется с экспертами, ищет материалы по нужной теме.

Но чиновники выше этой суеты они просто полагаются на чуйку!

Интуиция не подведет!Интуиция не подведет!

Когда депутаты пытаются выдумать из головы удачный закон они как слепцы, угадывающие направление посреди минного поля. Только за собой они ведут всю страну.

Не нужны никакие догадки. Любой продакт вам скажет, как искать релевантные гипотезы. Хотите развивать малый бизнес? Идите к предпринимателям и проводите глубинные интервью. Хотите прокачать туризм? Анализируйте опыт стран, которые на этом собаку съели. Хотите понять, что не так с дорогами? Изучайте статистику ДТП на карте.

Риск-менеджмент

Каждый раз, когда мы вносим значимые изменения в продукт мы выкатываем их поэтапно, чтобы минимизировать риски и не навредить нашим клиентам. А если это новый функционал даем к нему доступ только части пользователей, чтобы потом сравнить их метрики с контрольной группой.

Конечно, это сложнее, чем раскатать сразу и на всех.

Хорошо, что у депутатов нет таких проблем они без малейших сомнений могут принять новый закон, который затронет десятки миллионов человек. Безумие и отвага!

Выручает то, что большинство этих законов настолько плохо продуманы, что внедрить и проконтролировать их выполнение попросту невозможно.

Конечно, так быть не должно.

Не вижу ни одной причины, почему бы не обкатать закон сначала на маленькой аудитории или не устроить A/B-тест для оценки его влияния.

Думаю, многие заметили, как эффективно власть боролась с пандемией COVID-19. Когда из чертогов разума доставали какие-то странные правила и сразу применяли их к целым городам. Большинства фэйлов можно было бы избежать, если бы чиновники потратили хотя бы пару часов на локальные тесты каждого решения.

MVP

Прежде чем запускать очередной провальный нацпроект стоимостью в триллионы хорошо бы сделать небольшой прототип за 100$ и выяснить, что, оказывается, идея не жизнеспособна.

По моему опыту, практически любую идею можно проверить на коленке. Не всегда нужен даже прототип. Иногда достаточно лендинга, чтобы понять, есть ли интерес к продукту и какова будет стоимость привлечения пользователей.

Аналитика и дашборды

Как понять какая партия приносит пользу государству, а какая ему вредит?

Конечно, если партия десятки лет при власти, а население только беднеет из года в год, то можно что-то заподозрить. Но если власть все-таки сменяемая, то хотелось бы знать, кто как справляется. Ну или хотя бы кто больше ущерба стране нанес.

Какие инструменты стартапов могли бы тут помочь?

Общедоступный онлайн-дашборд позволил бы мониторить кто сколько инициатив-гипотез выдвинул, сколько поддержал, сколько из них были успешны и какой доход это принесло.

Что-то в таком духеЧто-то в таком духе

Это позволило бы оценить итоги работы любой партии или конкретного депутата. Если депутат генерит только убыточные законопроекты, то, возможно, стоит попросить его покинуть пляж.

Чтобы такой дашборд был возможен нужны экспертные и независимые аналитики. Возможно, четвертая, аналитическая ветка власти. Способная оценить итоги каждого законопроекта в цифрах. Более того никакой закон вообще нельзя принимать, пока аналитики не подтвердили, что смогут просчитать эффект от его внедрения.

Ну а чтобы исключить коррупционные схемы, когда аналитики шаманят с данными для конкретной партии все данные должны быть в общем доступе, чтобы перепроверить их мог любой желающий.

Human-centered design

В какой момент наши города превратились в токсичные парковки и безликие человейники? Почему люди на улицах упорно делают вид, что это нормально? Почему все сделано из пластика, сайдинга и какашек? Зачем так жить? Где архитектурные гайдлайны на уровне городов и государств? Где смертная казнь для людей, которые захламляют городскую среду рекламой?

Кхм, извините, в последнем вопросе во мне тоже проснулся депутат.

Типичные постсоветские пейзажи. Автор фотографий: Илья ВарламовТипичные постсоветские пейзажи. Автор фотографий: Илья Варламов

Что было бы со стартапом, который использует неудобный, некрасивый, устаревший дизайн? Вероятно, он потерял бы пользователей, которые ушли бы к конкуренту.

То же самое происходит и в наших странах. Люди заводят трактор и уезжают куда-то, где можно гулять по городу не испытывая хтонического ужаса. Разница только в том, что сменить мессенджер можно за пять минут, а переехать в другую страну для многих непосильная задача.

При этом ресурсов для создания хорошей городской среды часто требуется не больше, чем для плохой. Вопрос только в компетентности людей, которые этим занимаются.

Поэтому здесь дело даже не в методологии как таковой. А в понимании, что хороший продукт невозможен без хорошего дизайна. На это нужно выделять ресурсы точно так же, как и на другие потребности государства.

Бонус: пьеса Стыдоба. Или как чиновник продуктом управлял

Трагикомедия в 4-х действиях.

Действующие лица: продакт, чиновник, сисадмин, офис-менеджер, народные массы.

Читать

Действие первое

День до голосования на пост Chief Product Officer в крупном стартапе. Пасмурный опен-спейс с запотевшими окнами. Народные массы мнутся в нетерпении. Входит продакт с микрофоном.

П р о д а к т. Здравствуйте! Я проанализировал наши квартальные метрики и думаю, в ближайшее время мы должны сфокусироваться на увеличении среднего чека с платящего пользователя и конверсией во вторую поку

(Голос из толпы). Ску-у-учно!

Слышится неодобрительный гул толпы.

(Другой голос). Почему печенье заканчивается в четверг, что нам делать в пятницу?

П р о д а к т (сконфуженно). Но Позвольте Ведь вовсе не о том

Н а р о д (в едином порыве). Прочь! Позор! Прочь!

Продакт, понурившись, спешно покидает помещение.

Действие второе

Место действия то же. Входит чиновник в дорогом костюме.

Ч и н о в н и к. Привет, народ! Я вас люблю!

Толпа одобрительно аплодирует.

Ч и н о в н и к (грозя кулаком куда-то в сторону). А этим всем мы покажем! Нечего тут! Ишь!

Слышится радостное улюлюканье из зала.

Ч и н о в н и к. Я так скажу. К черту метрики! На хрен аналитику! Мы должны поднять всем зарплаты! Вдвое!

Толпа восторженно рукоплещет.

Ч и н о в н и к. Вместе мы сделаем наш продукт великим! Снова!

Народ ликует.

О ф и с - м е н е д ж е р (кричит из толпы). Я хочу от тебя детей! Мой голос за тебя!

Действие третье

Серверная. Темно, холодно. Сисадмин пьет чай. Входит чиновник.

Ч и н о в н и к. Хочу победить на выборах. Подшамань мне голоса. Вот бабла тебе принес.

С и с а д м и н. Ок.

Действие четвертое

Средиземное море, яхта качается на волнах. Чиновник выкидывает бутылку из-под шампанского за борт и надиктовывает будущие решения на диктофон, чтобы не забыть.

Ч и н о в н и к. Поувольнять, значица, оунеров энтих. Сестру туда поставлю и Димку своего.

Ненадолго прерывается, чтобы прожевать креветку.

Ч и н о в н и к. А еще неприкосновенность для руководства. И никакого контроля чтоб за расходованием средств. И обеспечить мне личного водителя, а то несолидно как-то...

Чешет пузо и переворачивается на другой бок. Шезлонг жалобно скрипит.

Ч и н о в н и к. Да! Про бездельников этих не забыть же. Увеличить штрафы за опоздания. И зарплаты порезать! А то ишь повадились!

Занавес

Короче, Склифосовский!

Ключевая мысль, которую я хочу донести, управление государством в нынешнем виде устарело. Модель, где сотни популистов перекрикивают друг друга, а потом голосуют это пережиток прошлого. Сегодня можно принимать обоснованные и взвешенные решения на основе кастдева и аналитики. И это не должны быть решения-законы. Это должны быть решения-гипотезы.

Именно так работает менеджмент стартапов. Чиновникам продуктовое мышление позволило бы не просто хаотично что-то делать тут и там, а системно улучшать жизнь в стране. Итерация за итерацией, спринт за спринтом.


P.S. Конечно, я прошелся по верхам просто чтобы проиллюстрировать идею. Но, может быть, у вас есть мысли какие методологии продуктового или проектного менеджмента хорошо зашли бы в госаппарат? Делитесь в комментариях, пожалуйста.

P.P.S. Должен признать: на самом деле весь этот эффективный менеджмент только полумеры. Потому что государством, очевидно, должна управлять нейросеть. Тогда любая система будет работать как следует хоть нейромонархия, хоть нейрокоммунизм.

Подробнее..

Как мы в компании умудрились провести 200 экспериментов в год и зачем это было нужно

02.04.2021 10:12:46 | Автор: admin

За более чем 8-летний опыт работы в продакт-сфере я работала на разных позициях: маркетологом, аналитиком, продакт-менеджером. Меня зовут Анастасия Бурдыко и я уже около года занимаю должность продакт-лида в Growth ветке Parimatch Tech. Совместными усилиями всей команды мы провели 200+ экспериментов, протестировали новый функционал, улучшили продукт и бизнес-результат. И по-прежнему продолжаем активно расти и развиваться. Так почему это столь важно? Перед тем как внедрять новые фичи и улучшать продукт, я считаю, что необходимо здраво оценить вероятный уровень эффективности. Это делается во избежание пустых время- и финансовых затрат.

На кого ориентирована данная статья? Владельцы, генеральные директора и продакт менеджеры, желающие сэкономить месяцы разработки и сотни тысяч долларов на проверке своих гипотез, определенно почерпнут для себя что-то полезное. Благодаря экспериментам все можно сделать максимально дешево и быстро. Такой подход к работе стал повседневностью в моей команде. Интересно? Значит, поехали дальше?

Эксперименты и способы их запуска

Что ж, эксперименты экономный, эффективный и простой способ проверки гипотез. Я абсолютно убеждена, прогресс невозможен, если он полагается только на одну лишь веру в идею. Во-первых, я считаю, вы должны получить хоть какое-то понимание, сработает ваша затея или нет, прежде чем переходить к ее масштабированию. Продуктовые компании время от времени начинают задумываться об эффективности новой функции, быстро переходя к ее внедрению, при этом, уделяя минимум времени проблеме и ее решению. Например, кто-то из руководства подсмотрел у конкурентов или других продуктов какую-то заманчивую функцию и захотел реализовать то же самое для своего бизнеса. Но нет понимания, какую именно ценность это решение принесет конкретному пользователю и принесет ли вообще что-нибудь. В этом случае мы не видим закрытия потребности, есть лишь желание что-то создать/ добавить. Однако, случается и так, что вы уже можете хоть примерно обрисовать проблему или нащупать потребность, но не можете определить эффективность функции, пока она не будет полностью актуализирована. Такое тоже случается. Но в большинстве случаев, вы всегда можете найти способ протестировать новшество перед его внедрением в производственную среду, не уничтожая свой бюджет и не нарушая дедлайны.

Ошибка всего лишь опыт. Если не тестировать новые гипотезы и не придумывать решения, качественный и быстрый рост просто не реален. Основоположная база экспериментов побуждает нас не только обнаруживать проблемы с продуктами, но и находить самые нестандартные решения. Поэтому, даже если во время эксперимента что-то пошло не так, не зацикливайтесь на своей неудаче, сделайте полезные выводы и двигайтесь дальше. Но что же мешает компаниям проводить эксперименты? Основная проблема нет времени на этот процесс. Вторая причина в том, что распорядок дня команды попросту не предусматривает такого рода деятельности.

Многие думают, что проведение экспериментов в компании проходит следующим образом: Смотри, у меня тут возникла мега-классная идея. Глянь, все ли работает. Это не имеет ничего общего с действительностью. Эксперимент предусматривает простой и оптимизированный процесс. Его основной принцип четко определять цели, формировать гипотезы, тестировать их и сосредотачиваться на улучшении бизнес показателей, на которые вы хотите повлиять.

Каждый эксперимент состоит из четырех основных компонентов: гипотезы, действия, сбор данных и выводов. Мы выводим теорию, проверяем ее, внимательно изучаем полученный результат и приходим к определенному итогу.

Наша командная работа построена таким образом, что мы совместно приходим к новым идеям. Для начала, определяем область роста продукта: проводим групповое занятие, рассматриваем нововведение со стороны пользователя и разбираем функционал продукта, имеющий непосредственное влияние на показатель, который мы хотим улучшить. Затем встречаемся с другими командами, демонстрируем, какие проблемы были обнаружены и какие решения мы можем предположить. Проводим коллективный мозговой штурм и вносим коррективы. После, расставляем приоритеты для всех гипотез в соответствии с критериями системы ICE влияние, уверенность и простота реализации. При этом, следует помнить, что последнее условие основное. Если эксперимент ориентировочно потребует больше 5 дней, то growth-команды могут запросто отказаться от его реализации.

Разработчики ключевой элемент, участвующий в проведении экспериментов. Это ребята, которые отвечают за техническую часть. Они не только активно генерируют идеи, но и играют важную роль в расстановке приоритетов и реализации фичи. До недавних пор, в ряду нашей команды были исключительно front-end-разработчики, так как мы тестили эксперименты только на фронте и передавали их core-командам для дальнейшей реализации. Сейчас у нас появился back-end специалист, поэтому теперь мы можем грамотно внедрять проверенные готовые решения непосредственно в продукт.

Практическая часть как все работает

Часто сотрудники не верят в эффективность эксперимента: они уверенны, что все и так работает замечательно, а затем искренне недоумевают из-за неожиданных результатов. Вот пример из жизни. Банальная ситуация, при регистрации на нашем сайте пользователь должен создать пароль, но при этом не было точных инструкций, какие символы нужно вводить. Когда мы попытались обсудить это с разработчиками, они сказали: Ну что тут сложного? В углу страницы есть вопросительный знак, и любой может, нажав на него, прочитать уточнение, если что-то настолько не очевидно.

Однако мы решили запустить эксперимент и создать более информативно-структурированное разъяснение пароля, где объяснялось, какие символы необходимо использовать для завершения регистрации (одна маленькая буква, одна заглавная и одна цифра). Результат превзошел все ожидания! За 2 часа нам удалось достичь + 64% к показателю конверсии при регистрации.

Другая история уже про экспериментирование с необходимостью повышения минимальной пользовательской ставки. Компания не была в восторге от этого эксперимента. Все думали, что такие действия приведут к негативным последствиям. Но мы рискнули и запустили эксперимент с небольшим количеством участников.

И никаких негативных последствий не было обнаружено. Наш саппорт не закидывали звонками и тухлыми помидорами. Все было более чем наглядно: мы осознали глубину ошибочных предположений о реакции юзеров, и насколько такое узкое мышление может тормозить прогресс. Поэтому, очень важно набраться смелости, чтобы опробовать все эксперименты, даже самые рискованные. В случае с последними, лучший способ проверить, как все работает, использовать небольшое количество пользователей.

Следуя этому простому совету, мы перестаем быть теми, кто просиживает штаны в офисе, свято веря, что они уже давным-давно все знают. Мы признаемся, что не можем знать наверняка, как пользователи будут себя вести, и каждый раз, проверяя новые гипотезы, делаем выводы и улучшаем продукт на основе практического опыта.

Почему неудачи часть успеха

У некоторых компаний есть идеология, которую можно описать так: Если ты совершаешь ошибку ты некомпетентен. В нашей компании другие принципы. Мы легко можем смириться с неудачей, особенно во время экспериментов. Сделав несколько ошибок, мы точно узнаем, работает наша гипотеза или нет, и получим ли мы возможность показать еще более крутой результат. Таким образом создается культура реальных результатов вместо смелых предположений.

Провальные эксперименты зачастую возникают, когда вы приступаете к работе с новыми функциями, с которыми ранее не имели дела. Например, одним из недавних экспериментов была попытка активации пассивной аудитории. Наша команда никогда с таким не сталкивалась, и, соответственно, у нас был нулевой опыт. Мы наивно полагали, что с помощью приложения сможем сразу же поймать необходимую аудиторию. Для решения этой задачи мы выгрузили всех безжизненных пользователей, разбили их на группы и запустили тест. Но оказалось, что установить эффективную связь было невозможно без привлечения их в продукт имейлами или смс, то есть без дополнительной коммуникации.

Было решено сосредоточиться на тех, кто в течении прошлого месяца посещал сайт менее двух раз в неделю. Они были предварительно выгружены из базы данных, и половина из них приняла участие в тестовой группе (где мы добавили новый функционал), а другая половина в контрольной, где его не было (классический аб тест). За время его проведения сайт посетило очень мало людей, которые должны были из предустановленного сегмента. Основной вывод - это то, что пользователей, которые редко заходят, на сайте не словишь без дополнительного стимула на него зайти. К огромному счастью, мы никогда не сталкивались с неудачными экспериментами, после проведения которых наши показатели производительности падали. Под провальными экспериментами подразумеваются те, которые не принесшие в результате улучшения, в которые мы свято верили.

Мы не теряем много денег на таких неудачах, поскольку цена ошибки покрывается стоимостью оперативной командной работы. Так как мы стараемся проводить небольшие и краткосрочные эксперименты, мы не тратим целое состояние на запуск определенной функциональности. Крупномасштабные эксперименты даже не отправляются в рабочий процесс. До тех пор, пока мы не будем уверены, что наша гипотеза сработает, мы отказываемся от пустых месяце-затрат разработки и выбрасывания бесконечных бюджетов на полный запуск новой функции. Поэтому, в таком ключе, провалы в экспериментах как экономят, так и приносят новые средства для компании.

Важно не только учиться на ошибках, но и делиться своим негативным опытом с другими командами. Для чего? Зачастую люди не особо задумываются над тем, почему что-то работает именно так, и не сомневаются в правильности или неправильности определенных действий. Но когда мы делимся опытом неудачных экспериментов в компании, многие начинают признавать возможность существования проблемы, которая может крыться с частности и в зоне их ответственности. Благодаря этому, другие коллеги также могут сомневаться в своих повседневных процессах и более активно тестировать новые гипотезы.

Маленькие хитрости для проведения экспериментов

В итоге, я собрала несколько правил, позволяющих превратить эксперименты в обычную корпоративную практику с удовлетворительными результатами:

Выстраивайте четкие цели. Это, пожалуй, ключевой компонент. Цель совокупность улучшения показателей и увеличения количества экспериментов.

Сосредоточьтесь на главном. Необходимо понять, что верно рассчитанное время для определенной метрики имеет большое значение. Например, на работу над страницей регистрации мы выделяем три месяца, а следующий триместр посвящаем другой задаче. Многие сотрудники хотят как можно скорее протестировать личные гипотезы и заимплементить само-придуманные функции. Поэтому, считаю важным удерживать внимание команды на текущем проекте, при этом не забывать правильно поддерживать индивидуальную инициативность, говоря: Это действительно потрясающая идея, но мы не можем ее сейчас реализовать. На данный момент, нашим приоритетом является другое направление.

Помните о простоте. MVP в квадрате девиз нашей команды. Термин MVP часто используется в контексте внедрения новых продуктов. Но это также относится и к экспериментам, поскольку чем быстрее вы получите отзывы пользователей, тем скорее сможете увеличить прибыль или существенно сэкономить.

Если перед нами стоит довольно обширная гипотеза, проверка которой требует больших время-затрат, мы максимально ее упрощаем и запускаем эксперимент в несколько этапов. Например, для того, чтобы понять насколько сильно пользователям понравятся нововведения, мы можем имитировать их. Маленький процент нашей аудитории получает доступ к улучшенному интерфейсу с новыми функциями, с которыми они могут взаимодействовать до определенного этапа, после чего увидят сообщение: Извините за неудобства, идет разработка. Благодаря этому, мы можем лучше понять и рассчитать, как пользователи реагируют на новые функции. Если они будут заинтересованы и активны, мы продолжим нашу работу, подключив серверную часть, в ином же случае не будем зря тратить ресурсы.

Нацельтесь на улучшение своих показателей. Когда люди участвуют в запуске инноваций, они, как правило, выполнив свою часть работы, скороспешно переключаются на другое задание, не утруждаясь проверить результат и отследить определенные показатели. Например, они обязуются запустить функции A, B и C через шесть месяцев. После того, как А была готова и запущена в продакшн, никто может и не заметить, что функция нерабочая. Такое происходит по причине того, что целью являются сами нововведения, а не улучшение метрик и конкретных бизнес-показателей. Если же все, наоборот, и результаты всегда имеют приоритет, то и разработка продукта воспринимается как ответственный и трудозатратный процесс, который требует постоянной переоценки того, на чем вам нужно сосредоточиться в данный момент. Значит, нацеливаясь на метрики, вы сможете выстроить правильный курс.

Где живут гипотезы и почему так важно превратить их в рутину

Если принцип подбора гипотез выглядит так На днях увидел классную фитчу, думаю, она может сработать и у нас, то никакого результата вам не видать. Очень важно определить, где заканчивается зона разработки продукта и что именно вы хотите усовершенствовать. Помимо аналитики конкурентов и метрик продукта, существуют и другие места и вдохновители для создания новых гипотез. Вот что лучше всего подходит для нас:

Исследование пользователей рутина. Например, ребята из нашей команды завели традицию по пятницам устраивать двухчасовые встречи с пользователями, для получения обратной связи. Подобного рода занятия довольно трудно перевести в рутину, но все же это вполне реально и действительно здорово работает. Ваши пользователи настоящий ящик Пандоры для генерирования новых гипотез. За каждым нашим успешным экспериментом стоит вовремя полученная обратная связь.

Каждая идея имеет значение. Сотрудники компании главные движущие силы экспериментов и творцы новых идей. Мотивируйте коллег подавать идеи по улучшению продукта, но помните, что игрой всегда управляете вы. Дайте четкое понимание, над какой областью продукта вы работаете в данный момент и какой у нее дедлайн, и используйте в работе только релевантные предложения.

Давайте сделаем выводы

Эксперименты дают компании уникальную возможность максимально быстро, эффективно и безболезненно протестировать идеи по улучшению продукта. Перед запуском новой важной функции, по моему опыту, лучше всего убедиться, что она вообще для кого-то актуальна. Более того, эксперимент, как часть рабочего процесса, допускает даже совершение ошибки, так как каждая неудача рассматривается как защитный барьер от бессмысленной траты крупных денежных средств компании. И разумеется, именно эксперименты демонстрируют реальный результат работы целой команды, совершенствуя все этапы разработки и внедрения гипотез. Так что, экспериментируйте и не забывайте делиться своим опытом в читателями. Надеюсь, вам было полезно узнать, как мы экспериментируем в Parimatch Tech, буду благодарна за любой фидбек в комментариях.

Подробнее..

Маленькими шагами к красивым решениям

16.05.2021 12:20:18 | Автор: admin

Архитектура ПО это Вселенная. Все очень сложно, но если все правильно, то все невероятно просто. Шаг за шагом познаю что и как. Ищу лучшие практики и шаблоны. В конечном счете, в очередной раз делаю одно и то же заключение:

Изученные правильные практики и шаблоны проектирования лишь вектор, который вдохновляет на красивые и уникальные решения.

Здесь нет примеров хорошей архитектуры, советов как должно быть и как правильно. Я просто хочу зафиксировать мысли, которые надо не забывать воспроизводить при решении очередной задачи.

Снаружи для пользователя, внутри для команды разработки

Архитектура системы определяет скорость ее развития. Красивая и правильная архитектура вдохновляет работать и помогает команде разработки.

Вдохновляет простое. К простым и красивым решениям не всегда возможно прийти с первого раза. Ошибка тоже результат.

Если система проста и удобна внутри, то она так же проста и удобна снаружи. У пользователей меньше проблем, а значит и у разработчиков тоже.

Если у команды разработки нет уверенности в последствиях их доработки, и они не могут точно сказать на что она повлияет, то это начало плохих решений: дублирование кода, неявная логика и другие причуда.

Монолиты плохо, микросервисы не всегда хорошо, наносервисы плохо. При проектировании нужно держать баланс и рисовать логические границы. Помогут сценарии использования.

Модель

Объектная модель должна быть понятна не только разработчикам, но и пользователям.

Модель должна быть гибкой: позволять масштабировать решение, не вызывать проблем при развитии. Нужно прогнать на ней все известные сценарии, которые будут реализованы сейчас и могут быть реализованы в будущем.

При реализации объектной модели клиентам рекомендуется ориентироваться на модель сервер-приложения.

Логика

Упрощайте алгоритмы. Делите сложные части на простые. Не переусердствуйте.

Сначала продумайте тесты для алгоритма, получите альтернативные сценарии и предусмотрите обработку, а потом пишите сам алгоритм.

Если какая-то часть алгоритма многократно повторяется, то скорее всего она должна быть выделена в отдельный модуль и переиспользоваться. Отдельный модуль отдельный алгоритм.

Алгоритм должен легко читаться: в тексте, в любой нотации моделирования, в коде.

Не прячьте за методами в коде неявную логику. Неявные связи в реализации логики ведут к усложнению решения.

Когда отдельные части программы нельзя перекомбинировать в новое целое, значит создан неэффективный монолит.

Нейминг решает

Если назвать бокал стаканом, то назначение "пить" вроде бы не меняется, но что-то все-таки не то.

Имя объекта должно характеризовать его достаточно емко, не вызывать двусмысленности.

Метод должен реализовывать ровно то, о чем говорит его название. Название должно быть таким, чтобы другому разработчику не нужно было залезать внутрь и раскапывать, что еще здесь можно неожиданно встретить в реализации. Лучше, когда название метода описывает результат его работы, но не его реализацию.

Имена объектов и методов в конечном счете становится языком команды разработки, заказчика ПО и даже пользователей.

MVP и прототипы

MVP это быстро и просто, это способ сдвинуться с мертвой точки и начать показывать результат.

MVP лучше, чем волшебное ничего и долгое обсуждение, как же все-таки надо сделать. Это отличный способ собрать фидбэк и неявные требования от пользователей, от других команд разработки, которые будут использовать ваше решение.

Рефакторинг

Это придется делать. Это нормально и это важно. Даже для задач, выпущенных в продакшн совсем недавно.

Своевременный рефакторинг ускоряет разработку. Больше времени сегодня на задачу, в рамках которой надо сделать рефакторинг, меньше времени на будущие задачи.

Заботьтесь о том, чтобы в будущем код не вызывал страха и отвращения к рефакторингу. С ним должно быть приятно работать. Если нет четкой и понятной архитектуры, то программисты будут бояться даже заглянуть в код, чтобы понять как это работает.

Рефакторингу может быть подвергнуто все, что связано с системой: код, модель данных, алгоритмы, тест-кейсы.

Документация

Документация к системе должна дополнять программный код и хранить знания о причинах принятых архитектурных решений.

Документация к системе позволяет без доступа к коду понимать, как работает программа: реализацию алгоритма, покрытие альтернативных сценариев, обработку ошибок. Но разработчикам должен быть понятен код и без документации на него.

Выводы

Не усложнять.

Ничего не прятать.

Называть все своими именами.

Не стоять на месте.

Не поддаваться отчаянию, если не получилось.

Не забывать переосмысливать: смотреть через несколько дней свежим взглядом на готовое решение, если время позволяет.

Подробнее..

Из песочницы Как определить функционал MVP и влюбить клиента в пилотную версию продукта

04.07.2020 00:19:48 | Автор: admin

Итак, MVP. Достаточно заезженная тема, на мой взгляд. Каждый, кто хоть как-то связывал себя с разработкой программного обеспечения за последние 5 лет, с 99% вероятностью слышал эти 3 буквы. Но даже несмотря на обилие информации, народ все равно наступает на грабли идеального продукта при создании проектов.


Эта статья не претендует на то, чтобы быть истиной в последней инстанции. Она не про важность и необходимость MVP. И не про его роль в бережливом запуске стартапов. Я просто порассуждаю о том, каким должен быть минимально жизнеспособный продукт на момент пилотного выхода на рынок.


Начну с вирусной зарисовки пути развития стартапа по принципу MVP, которая гуляет по интернету и которую вы наверняка встречали.


image


90% авторов используют иллюстрацию в своих публикациях в буквальном смысле, что вводит в заблуждение читателей.


Разберем?


Верхняя строка ничего общего с MVP не имеет. Это понятно. На ней изображен классический цикл разработки. Автор использовал его как преувеличение ради контекста в примере ниже. Разумеется, ни о каком минимально жизнеспособном продукте на первом этапе с колесом речи и быть не может. Продукт прошел 3 стадии разработки (колеса, кузов, двигатель), прежде чем смог выполнить свое предназначение ехать.


Но и вторая строка, на мой взгляд, также не совсем корректно отображает принцип MVP.


Почему мое внутреннее понимание минимально жизнеспособного продукта не сходится с такой концепцией? Если предположить, что она отражает путь разработки какого-то продукта, становится очевидно, что он претерпел 4 коренных перестройки. В итоге его создатели получили три группы товарно-родовых конкурентов: 1 скейт-самокат-велосипед; 2 мотоцикл; 3 автомобиль.


Да, покупатель, как мы знаем, покупает не продукт, а решение своей проблемы. И скейт вроде бы решает базовую потребность (передвигаться быстрее, чем пешком). Но ведь скейт и автомобиль это абсолютно разные средства передвижения, нацеленные на разную аудиторию и цель езды для каждого из них имеет совершенно разную специфику. Продукты по-разному удовлетворяют запросы к комфорту, цене, сложности техобслуживания, скорости и т.д. В результате, у каждого своя целевая аудитория.


У автомобиля более широкий охват: пожилые и молодые люди, те, кто путешествует в одиночку или в компании, кто ездит на работу или мотается в другой город им нужна скорость, комфортное размещение и езда при любых погодных условиях. Скейт предназначен исключительно для одного человека, чаще ребенка или подростка, да и цель езды носит больше развлекательный характер. Аудитория скейта воспримет в штыки перспективу трансформации продукта в машину, которой нужно топливо, дорогостоящее ТО и возраст 17+, не говоря уже о цене самого автомобиля. А те, кому нужна машина, изначально не обратят на ваш самокат никакого внимания. Да, каждый из этих продуктов может иметь MVP, но они не являются MVP друг для друга.


Хенрик Книберг, автор этой картинки, не раз писал о том, что его изображение не всегда интерпретируется в правильном контексте. Дело в том, что он вкладывал в нее метафорический смысл, при котором цель разработки не построить автомобиль, а решить задачу добраться из пункта А в пункт Б. И самым простым жизнеспособным вариантом решения этой задачи является скейт. То есть на ней абстрактно и очень упрощенно передан некий концепт поиска продукта. Скейт или самокат не являются MVP для машины. Это факт. На картинке лишь изображена идея того, что в рамках создания продукта можно сделать несколько пивотов и в итоге найти MVP.


А эта переосмысленная версия MVP мне больше пришлась по душе:


image


В продуктовом бизнесе MVP продукта это сам продукт, только выполненный с какими-то упрощениями, сокращениями, удешевлениями. MVP высотного здания это та же высотка, но не на 24 этажа, а на 5, без лифта, мусоропровода и прочих благ. MVP автомобиля это автомобиль. Только попроще. Сначала из досок и сваренной на скорую руку рамой, с двигателем послабее (или вообще без него), сидениями от мебельного гарнитура. Но три ключевые функции, отстраивающие его от скейта или самоката, скорость, вместительность и дальние поездки уже будут при нем.


Что завернуть в MVP, чтобы его захотели попробовать?


С концепцией MVP разобрались. Теперь поговорим о том, как определить начинку пилотного продукта, приоритезировать функционал и сделать первую версию продукта востребованной.


Первое, что необходимо сделать, это выяснить, какие инструменты, фичи и возможности станут для вашего продукта must have.


image


Принцип Парето


20% усилий дают 80% результата, а остальные 80% усилий лишь 20% результата. Это эмпирический принцип, а значит многие явления в мире, в том числе и разработка, подчиняются такому соотношению. 80% ваших пользователей будут использовать только 20% функционала. Поэтому не нужно тратить месяцы на то, чтобы отполировать до кристального сияния свой продукт перед запуском. Пропишите полный перечень функций будущего приложения и определите те 20%, которые закроют 80% потребностей пользователей.


MVP = обязательно + просто


Слышали про матрицу приоритетов? Популярная техника приоритезации задач, которая распределяет фичи по шкалам обязательно и просто. Изобразите две оси, где горизонтальная будет отображать увеличение сложности реализации конкретной функции, а вертикальная путь от желательного к обязательному. Раскидайте весь запланированный функционал на этой схеме, отвечая на 2 вопроса:


  1. Сложно это или легко для реализации?
  2. Желательно это или обязательно для пользователя?

image


Получив готовый список с помощью этой матрицы, можно смело обращаться к разработчикам.


Формула Rice Score


Еще один эффективный метод приоритезации идей и фич для MVP. Вам нужно оценить каждую функцию по четырем факторам и подставить значения в простую формулу.


  • Охват скольким пользователям вы улучшите жизнь?
    (Оцените в течение определенного периода времени и берите цифры из метрик, а не с потолка)
  • Влияние насколько вы улучшите жизнь пользователям?
    (Очень сильно = 3х, сильно = 2х, хорошо = 1х, слабо = 0,5х, совсем немного = 0,25х)
  • Уверенность насколько вы уверены, что гипотеза окажется верна и продукт выстрелит?
    (100% = высокая уверенность, подтвержденная опросами или исследованиями, 80% = средняя уверенность, 50% = слабая уверенность, 50% и ниже = много сомнений)
  • Усилия сколько человеко-часов, человеко-дней или просто дней уйдет на реализацию?
    (1 человеко-день = это день работы одного разработчика)

Рассчитайте оценку для каждой фичи, согласно формуле:


image


Вместо итога


MVP подход играет роль подушки безопасности и позволяет адекватно прогнозировать коммерческий и технический потенциал продукта. Поэтому, когда мы брифуем заказчиков, то настаиваем на том, что стартовать разработку лучше с него. И, разумеется, помогаем определиться с ключевым функционалом. Если вы планируете создание минимально жизнеспособного продукта, то лучший вариант построить его на NoCode технологии. Сегодня платформы для разработки приложений без кода пользуются бешеным спросом. Они позволяют быстрее и дешевле создавать web-приложения любой сложности, а существующие биржы NoCode фриланса помогают подобрать подходящую под запросы бизнеса технологию и проверенного специалиста. Осмелюсь предположить, что тенденция к упрощению и удешевлению разработки будет только усиливаться. И сейчас самое время задействовать ее потенциал.

Подробнее..

Как подружить RxJava с VIPER в Android, подходы применения и о структуре планировщиков

23.07.2020 18:11:16 | Автор: admin
image

Привет, Хабровчане. Сегодня мы с вами поговорим о RxJava. Я знаю, что о ней написано материала вагон и маленькая тележка, но, как мне кажется, у меня есть пара интересных моментов, которыми стоит поделиться. Сначала расскажу, как мы используем RxJava вместе с архитектурой VIPER для Android приложений, заодно посмотрим на классический способ применения. После этого пробежимся по главным особенностям RxJava и остановимся подробнее на том, как устроены планировщики. Если вы уже запаслись вкусняшками, то добро пожаловать под кат.

Архитектура, которая подойдет всем


RxJava это реализация концепции ReactiveX, а создала эту реализацию компания Netflix. В их блоге есть цикл статей о том, зачем они это сделали и какие проблемы они решили. Ссылки (1, 2) вы найдете в конце статьи. Netflix использовали RxJava на стороне сервера (backend), чтобы распараллелить обработку одного большого запроса. Хотя они предложили способ применения RxJava на backend, такая архитектура подойдет для написания разных типов приложений (мобильные, desktop, backend и многих других). Разработчики Netflix использовали RxJava в сервисном слое таким образом, чтобы каждый метод сервисного слоя возвращал Observable.

Дело в том, что элементы в Observable могу доставляться синхронно и асинхронно. Это дает возможность методу самому решать, возвращать значение сразу синхронно, (например, если оно доступно в кэш) или сначала получить эти значения (например, из базы данных или удаленного сервиса) и вернуть их асинхронно. В любом случае, управление будет возвращаться сразу после вызова метода (либо с данными, либо без).

/** * Метод, который сразу возвращает значение, если оно * доступно, или использует  другой поток исполнения, * чтобы получить значение и передать его через callback `onNext()` */public Observable<T> getProduct(String name) {    if (productInCache(name)) {        // Если данные доступны, возвращаем их сразу        return Observable.create(observer -> {           observer.onNext(getProductFromCache(name));           observer.onComplete();        });    } else {        // Иначе задействуем другой поток исполнения        return Observable.<T>create(observer -> {            try {                // Выполняем работу в отдельном потоке                T product = getProductFromRemoteService(name);                // вовращаем значение                observer.onNext(product);                observer.onComplete();            } catch (Exception e) {                observer.onError(e);            }        })        // Говорим Observable использовать планировщик IO        // для создания/получения данных        .subscribeOn(Schedulers.io());    }}

При таком подходе мы получаем один неизменный API для клиента (в нашем случае контроллер) и разные реализации. Клиент всегда взаимодействует с Observable одинаково. Ему абсолютно не важно, получены ли значения синхронно или нет. При этом реализации API могут меняться от синхронных к асинхронным, никак не затрагивая взаимодействие с клиентом. С помощью такого подхода можно совершенно не задумываться о том, как организовать многопоточность, и сосредоточиться на реализации бизнес задач.

Подход применим не только в сервисном слое на backend, но и в архитектурах MVC, MVP, MVVM и др. Например, для MVP мы можем сделать класс Interactor, который будет ответственным за получение и сохранение данных в различные источники, и сделать так, чтобы все его методы возвращали Observable. Они будут являться контрактом взаимодействия с Model. Это также даст возможность использовать в Presenter всю мощь операторов, имеющихся в RxJava.

image

Мы можем пойти дальше и сделать реактивным API уже у Presenter, но для этого нам понадобится правильно реализовать механизм отписки, позволяющий всем View одновременно отписаться от Presenter.

Дальше посмотрим на пример применения такого подхода для архитектуры VIPER, которая является усовершенствованным MVP. Также стоит помнить, что нельзя делать Observable singleton объектами, потому что подписки к таким Observable будут порождать утечки памяти.

Опыт применения в Android и VIPER


В большинстве текущих и новых Android проектов мы используем архитектуру VIPER. Я познакомился с ней, когда присоединился к одному из проектов, в котором она уже использовалась. Помню, как удивился, когда у меня спросили, не смотрел ли я в сторону iOS. iOS в Android проекте?, подумал я. А между тем, VIPER пришел к нам из мира iOS и по сути является более структурированной и модульной версией MVP. О VIPER очень хорошо написано в этой статье (3).

Поначалу все казалось хорошо: правильно разделенные, не перегруженные слои, у каждого слоя своя область ответственности, понятная логика. Но через какое-то время стал проявляться один недостаток, а по мере роста и изменения проекта он стал очень даже мешать.

Дело в том, что мы использовали Interactor так же, как и коллеги в своей статье. Interactor реализует небольшой use case, например, скачать продукты из сети или взять продукт из БД по id, и выполняет действия в рабочем потоке. Внутри себя Interactor совершает операции, используя Observable. Чтобы запустить Interactor и получить результат, пользователь реализует интерфейс ObserverEntity вместе с его методами onNext, onError и onComplete и передает его вместе с параметрами в метод execute(params, ObserverEntity).

Вы, наверное, уже заметили проблему структура интерфейса. На практике нам редко нужны все три метода, часто используются один или два из них. Из-за этого в коде могут встречаться пустые методы. Конечно, мы можем пометить все методы интерфейса default, но такие методы скорее нужны для добавления новой функциональности в интерфейсы. К тому же, странно иметь интерфейс, все методы которого опциональны. Мы также можем, например, создать абстрактный класс, который наследует интерфейс, и переопределять нужные нам методы. Или, наконец, создать перегруженные версии метода execute(params, ObserverEntity), которые принимают от одного до трех функциональных интерфейсов. Эта проблема плохо сказывается на читаемости кода, но, к счастью, довольно просто решается. Однако, она не единственная.

saveProductInteractor.execute(product, new ObserverEntity<Void>() {    @Override    public void onNext(Void aVoid) {        // Сейчас этот метод нам не нужен,        // но мы обязана его реализовать    }    @Override    public void onError(Throwable throwable) {        // Сейчас этот метод используется        // Какой-то код    }    @Override    public void onComplete() {        // И этот метод тоже используется        // Какой-то код    }});

Кроме пустых методов, есть и более неприятная проблема. Мы используем Interactor, чтобы выполнить какое-то действие, но почти всегда это действие не является единственным. Например, мы можем взять продукт из базы данных, затем получить о нем отзывы и картинку, затем сохранить все это в другое место и в конце перейти на другой экран. Тут у нас каждое действие зависит от предыдущего и при использовании Interactor-ов мы получаем огромную цепочку из колбэков, прослеживать которую бывает очень утомительно.

private void checkProduct(int id, Locale locale) {    getProductByIdInteractor.execute(new TypesUtil.Pair<>(id, locale), new ObserverEntity<Product>() {        @Override        public void onNext(Product product) {            getProductInfo(product);        }        @Override        public void onError(Throwable throwable) {            // Какой-то код        }        @Override        public void onComplete() {        }    });}private void getProductInfo(Product product) {    getReviewsByProductIdInteractor.execute(product.getId(), new ObserverEntity<List<Review>>() {        @Override        public void onNext(List<Review> reviews) {            product.setReviews(reviews);            saveProduct(productInfo);        }        @Override        public void onError(Throwable throwable) {            // Какой-то код        }        @Override        public void onComplete() {            // Какой-то код        }    });    getImageForProductInteractor.execute(product.getId(), new ObserverEntity<Image>() {        @Override        public void onNext(Image image) {            product.setImage(image);            saveProduct(product);        }        @Override        public void onError(Throwable throwable) {            // Какой-то код        }        @Override        public void onComplete() {        }    });}private void saveProduct(Product product) {    saveProductInteractor.execute(product, new ObserverEntity<Void>() {        @Override        public void onNext(Void aVoid) {        }        @Override        public void onError(Throwable throwable) {            // Какой-то код        }        @Override        public void onComplete() {            goToSomeScreen();        }    });}

Ну, как вам такая макаронина? При этом у нас простая бизнес логика и одинарная вложенность, а представьте, что было бы с более сложным кодом. Это также затрудняет повторное использование метода и применение разных планировщиков для Interactor.

Решение на удивление простое. Вы чувствуете, что этот подход пытается повторить поведение Observable, но делает это неправильно и сам создает непонятные ограничения? Как я уже рассказывал раньше, этот код достался нам из уже существующего проекта. При исправлении этого legacy-кода будем использовать подход, который завещали нам ребята из Netflix. Вместо того, чтобы каждый раз реализовывать ObserverEntity, заставим Interactor просто возвращать Observable.

private Observable<Product> getProductById(int id, Locale locale) {    return getProductByIdInteractor.execute(new TypesUtil.Pair<>(id, locale));}private Observable<Product> getProductInfo(Product product) {    return getReviewsByProductIdInteractor.execute(product.getId())    .map(reviews -> {        product.set(reviews);        return product;    })    .flatMap(product -> {        getImageForProductInteractor.execute(product.getId())        .map(image -> {            product.set(image);            return product;        })    });}private Observable<Product> saveProduct(Product product) {    return saveProductInteractor.execute(product);}private doAll(int id, Locale locale) {    // Берем продукт из хранилища    getProductById (id, locale)    // Добавляем информацию    .flatMap(product -> getProductInfo(product))    // Сохраняем все в другое хранилище    .flatMap(product -> saveProduct(product))    // После сохранения продукты в потоке больше не нужны    .ignoreElements()    // Устанавливаем планировщики    .subscribeOn(Schedulers.io())    .observeOn(AndroidSchedulers.mainThread())    // Переходим на другой экран    .subscribe(() -> goToSomeScreen(), throwable -> handleError());}

Вуаля! Так мы не только избавились от того громоздкого и неповоротливого ужаса, но и привнесли мощь RxJava в Presenter.

Концепции в основе


Я довольно часто встречал, как с помощью функционального реактивного программирования (далее ФРП) пытались объяснить концепцию RxJava. На самом деле, оно никак не связано с этой библиотекой. ФРП больше о непрерывных динамически изменяемых значениях (поведениях), непрерывном времени и денотационной семантике. В конце статьи вы сможете найти пару интересных ссылок (4, 5, 6, 7).

В качестве основных концепций RxJava использует реактивное программирование и функциональное программирование. Реактивное программирование можно описать как последовательную передачу информации от наблюдаемого объекта объекту-наблюдателю таким образом, что объект-наблюдатель получает ее автоматически (асинхронно) по мере возникновения этой информации.

Функциональное программирование использует понятие чистых функций, то есть тех, которые не используют и не изменяют внешнее состояние; они полностью зависят от своих входных данных для получения своих выходных данных. Отсутствие у чистых функций побочных эффектов дает возможность использовать результаты одной функции в качестве входных параметров другой. Это дает возможность составлять неограниченную цепочку функций.

Соединение этих двух концепций вместе наряду с использованием GoF шаблонов Observer и Iterator позволяет создавать асинхронные потоки данных и обрабатывать их с помощью огромного арсенала очень удобных функций. Это также дает возможность очень просто, а главное безопасно, использовать многопоточность, не думая о таких ее проблемах как синхронизация, неконсистентность памяти, наложение потоков и т.д.

image

Три кита RxJava


Основные три компонента, на которых строится RxJava Observable, операторы и планировщики.
Observable в RxJava отвечает за реализацию реактивной парадигмы. Observable часто называют потоками, так как они реализуют как концепцию потоков данных, так и распространение изменений. Observable это тип, который достигает реализации реактивной парадигмы за счет объединения в себе двух шаблонов из книги Gang of Four: Observer и Iterator. Observable добавляет в Observer две отсутствующие семантики, которые есть в Iterable:

  • Возможность для производителя сигнализировать потребителю о том, что больше нет доступных данных (цикл foreach в Iterable завершается и просто возвращается; Observable в этом случае вызывает метод onCompleate).
  • Возможность для производителя сообщать потребителю, что произошла ошибка и Observable больше не может испускать элементы (Iterable бросает исключение, если во время итерации возникает ошибка; Observable вызывает метод onError у своего наблюдателя и завершается).

Если Iterable использует pull подход, то есть потребитель запрашивает значение у производителя, и поток исполнения блокируется до тех пор, пока это значение не прибудет, то Observable является его push эквивалентом. Это значит, что производитель отправляет значения потребителю, только когда они становятся доступны.

Observable это только начало RxJava. Он позволяет асинхронно получать значения, но настоящая мощь приходит с реактивными расширениями (отсюда ReactiveX) операторами, которые позволяют преобразовывать, комбинировать и создавать последовательности элементов, испускаемых Observable. Именно тут и выходит на передний план функциональная парадигма со своими чистыми функциями. Операторы используют эту концепцию в полной мере. Они позволяют безопасно работать с последовательностями элементов, которые испускает Observable, не боясь побочных эффектов, если, конечно, не создать их самостоятельно. Операторы позволяют применять многопоточность, не заботясь о таких проблемах как потокобезопасность, низкоуровневое управление потоками, синхронизация, ошибки некосистентности памяти, наложение потоков и т.д. Имея большой арсенал функций, можно легко оперировать различными данными. Это дает нам очень мощный инструмент. Главное помнить, что операторы модифицируют элементы, испускаемые Observable, а не сами Observable. Observable никогда не изменяются с момента их создания. Размышляя о потоках и операторах, лучше всего думать диаграммами. Если вы не знаете, как решить задачу, то подумайте, посмотрите на весь список доступных операторов и подумайте еще.

Хотя сама по себе концепция реактивного программирования является асинхронной (не путайте с многопоточностью), по умолчанию все элементы в Observable доставляются подписчику синхронно, в том же потоке, в котором был вызван метод subscribe(). Чтобы привнести ту самую асинхронность, нужно либо самостоятельно вызывать методы onNext(T), onError(Throwable), onComplete() в другом потоке исполнения, либо использовать планировщики. Обычно все разбирают их поведение, так что давайте посмотрим на их устройство.

Планировщики абстрагируют пользователя от источника параллелизма за собственным API. Они гарантируют, что будут предоставлять определенные свойства, независимо от лежащего в основе механизма параллельности (реализации), например, Threads, event loop или Executor. Планировщики используют daemon потоки. Это означает, что программа завершится вместе с завершением основного потока исполнения, даже если происходят какие-то вычисления внутри оператора Observable.

В RxJava есть несколько стандартных планировщиков, которые подходят для определенных целей. Все они расширяют абстрактный класс Scheduler и реализуют собственную логику управлением workers (рабочими). Например, планировщик ComputationScheduler во время своего создания формирует пул рабочих, количество которых равно количеству процессорных потоков. После этого ComputationScheduler использует рабочих для выполнения Runnable задач. Вы можете передать Runnable планировщику с помощью методов scheduleDirect() и schedulePeriodicallyDirect(). Для обоих методов планировщик берет очередного рабочего из пула и передает ему Runnable.

Рабочий находится внутри планировщика и представляет собой сущность, которая выполняет Runnable объекты (задачи), используя одну из нескольких схем параллельности. Другими словами, планировщик получает Runnable и передает ее рабочему для выполнения. Также можно самостоятельно получить рабочего у планировщика и передать ему один или несколько Runnable, независимо от других рабочих и самого планировщика. Когда рабочий получает задачу, он помещает ее в очередь. Рабочий гарантирует последовательное выполнение задач в том порядке, в котором они были переданы, однако порядок может нарушаться отложенными задачами.

Например, в планировщике ComputationScheduler рабочий реализован с помощью ScheduledExecutorService размером в один поток.

image

Таким образом, мы имеем абстрактных рабочих, которые могут реализовывать любую схему параллельности. Такой подход дает много плюсов: модульность, гибкость, один API, различные реализации. Похожий подход мы видели в ExecutorService. К тому же, мы можем использовать планировщики отдельно от Observable.

Заключение


RxJava очень мощная библиотека, которую можно использовать самыми разными способами во множестве архитектур. Способы ее применения не ограничиваются уже существующими, поэтому всегда пробуйте адаптировать ее под себя. Однако помните о SOLID, DRY и других принципах разработки, а также не забывайте делиться с коллегами своим опытом применения. Надеюсь, что вы смогли почерпнуть из статьи что-то новое и интересное, до встречи!

  1. Причины, почему Netflix начали использовать ReactiveX
  2. Презентация RxJava интернет-сообществу
  3. Объяснение архитектуры VIPER и пример применения
  4. Объяснение ФРП от его создателя
  5. Разница между ФРП и реактивным программированием
  6. Рассуждение о ФРП
  7. Блог Conal Elliot о ФРП
Подробнее..

Как все-таки экономить на мобильной разработке?

18.03.2021 12:07:58 | Автор: admin

В предыдущем обзоре я перечислила лажовые способы сэкономить, и, возможно, вы впали в отчаяние, начали много курить и с опаской смотреть на ту дверь, в которую вам предстоит вносить бюджетную смету на проект. Это понятно, бюджеты ни у кого не резиновые, а работать надо. И если есть экономия курильщика, должна же быть экономия здорового человека, иначе в чем смысл экспоната. Рассказываю.

Любое приложение, если уж совсем упрощать, состоит из двух базовых слагаемых дизайн и функционал. Хорошая новость экономить можно и на том и на другом.

Экономия на функционале

Есть такая штука, которая называется MVP Minimum Viable Product. То есть, минимально жизнеспособный продукт.

Вот у вас есть супер-идея. Доставка апельсинов по Москве. Вы уверены, что это взорвет рынок здесь и сейчас. Вы фантазируете миллион способов доставки, выбор апельсинов по весу, размеру и толщине кожуры. Возможность нанести на апельсин лого компании и поздравление с днем рождения. Букеты из апельсинов, мерч, футболки с логотипом вашей компании и коллаборацию в ютьюбе с Собчак.

Это все, конечно, замечательно. Но разумнее на первых порах ограничиться самым минимальным набором опций, как в бизнесе, так и в создаваемом под бизнес-задачи приложении.

Создайте качественное, масштабируемое, вменяемое с точки зрения кода и удобное с точки зрения пользователя приложение. И пусть там будет всего два экрана выбрать апельсин и заказать доставку по адресу. И третий с вашей фирменной фишкой, например нанесением имени и поздравления на апельсин.

Все. Этого достаточно, чтобы запуститься и посмотреть на реакцию уважаемой публики. Остальные опции, расширения, возможности и финтифлюшки оставьте как точки роста.

Можно начертить роудмап и развивать приложение по нему. Третий квартал 2021 добавляем возможность нанесение кастомного принта на апельсин. Четвертый квартал 2021 GPS треккинг курьера с апельсинами. Первый квартал 2022 создание рекомендательного сервиса для сортов апельсинов

Быстро это медленно, но постоянно. А еще по верному пути. Ограничьтесь MVP для запуска и, если все пройдет хорошо, свистелок накрутить всегда успеете. Если все плохо снизите потери.

Экономия на дизайне

Конечно, хочется, чтобы красиво. А еще хочется, чтоб не как у всех. Хочется поражать, влюблять, вызывать почти что физиологическое привыкание.

Мы сделаем такие иконки, что вам захочется их лизнуть!. А мы такой дизайн всего остального, что вам захочется его раздробить и втянуть носом через стодолларовую бумажку. Тем более, что мы таких бумажек теперь еще долго не увидим, ибо все потратили на дизайн.

Максим Никитин уже говорил, что вычурно не значит хорошо. Если у вас не так, как у всех, это совсем не значит, что у вас лучше. А еще, если у вас дороже это тоже не значит, что этим удобнее пользоваться или вообще, что это хоть кто-то заметит.

В iOS и Андроиде есть так называемые гайдлайны объемистые списки рекомендаций, как надо делать дизайн, чтобы вас не прокляли ни разработчики ни юзеры. Если им следовать и размещать все кнопки там, где их ожидают найти, то можно сэкономить кучу сил программистам, денег себе и нервов пользователям.

Стандартные решения это не плохо. Минимум анимации это еще и минимум тормозов на недорогих телефонах. Хитрые элементы, загадочные тенюшки, всплывающие непонятно откуда элементы: все это смотрится круто на презентациях, в реальности же оказывается часто ненужным, второстепенным, а иногда и вовсе мешает бодрому выводу приложения на рынок.

Если вы ограничены во времени и бюджете да обойдитесь вы стандартными шаблонами, простыми рекомендациями и всем понятным интерфейсом. Выкрасите все в брендовые цвета и нарисуйте хорошую иконку. Все. Для хорошего старта больше и не надо.

Экономия на платформе

Да, надо писать натив. Да, на обе платформы и да, черт бы побрал это всемирное разделение на яблочников и андроидов. Да, это в два раза больше денег. А если нет?

Недавний взлет Clubhouse демонстрирует лучше любых уговоров выпусти только под одну платформу, пусть все передерутся. Андроидопользователи костылят сумасшедшие решения, чтобы запускать приложение на PC, яблочники нашли еще один повод демонстрировать свое восхитительное превосходство на одинаковых аппаратах, взятых в кредит. Все жужжат, скачивания идут.

Такой джекпот сорвать удается, конечно, не каждому, но в целом схема рабочая. Присмотритесь к своей ЦА, может быть пользователей Apple в ней ничтожно мало? Выпускайтесь тогда на Андроиде, а на iOS анонсируйте через полгода-год. Или наоборот, вам интересная только аудитория iOS, потому что основной способ монетизации внутренние покупки в приложении? Тогда да, яблочники принесут гораздо больше, а Андроид может и подождать.

Экономия ультимативная

Вообще, все вышеперечисленные способы об одном и том же. Не надо делать все и сразу делайте все и постепенно.

Создайте MVP и развивайте его по мере необходимости. Начните с простого дизайна и обновляйте его, когда появляется возможность или необходимость. Напишите под одну платформу, вторую добавите позже.

А знаете что еще можно? Можно вообще не писать приложение.

Да, это забавно, когда сапожник предлагает вам ходить без сапог, но баблишко мы, конечно любим, а истина дороже.

Если у вас есть хороший качественный сайт и мобильная версия этого сайта выполняет весь необходимый на данный момент функционал, бюджет туговат, проект маловат может вам сейчас и не нужно мобильное приложение?

Мобильные маркеты переполнены наспех напиленными, никому ненужными кривыми приложениями. Зачем множить бездну? Зачем сливать время и бюджет в никуда? Может лучше заложить его на следующий, например, год, и сделать потом хорошо? Лучше, чем сейчас и черти как. А за этот год провести хорошую аналитику, выбрать достойную команду, понять дальнейшие точки роста и что именно вам нужно от приложения на начальном этапе.

В конце концов, невозможно сэкономить на проекте сильнее, чем полностью от него отказавшись.

Подробнее..

Из песочницы Помощник в проведении технического интервью и совместный кодинг

20.11.2020 16:08:20 | Автор: admin


Сколько мне довелось пройти технических собеседований на фронтенд разработчика, столько разных способов и инструментов на них использовали интервьюеры.

Чат в одном месте, созвон в другом, кодинг в третьем. Ой, что-то не работает этот сервис, а расшарь-ка экран. Ой, код решения отвалился, ну напиши снова И без того стрессовая ситуация для кандидата превращается в неприятную карусель.

И по такому же сценарию выстроена структура интервью чаще хаос, перескакивания с темы на тему.

Я пытаюсь сделать простой, удобный и бесплатный сервис для технического собеседования, как для интервьюера, так и для кандидата. Всё в одном месте для всех: заметки, отчет и прочие фичи для интервьюера, и удобный редактор, полноценный и красивый фидбек на почту и т.п. для кандидата.

Чтобы всё было предсказуемо и по стандартам, ведь столько статей о правильном проведении интервью написано на хабре. Есть чем вдохновляться.

Назвал его Meet2Code.

Что есть на данный момент:

  • Анкета на каждый раздел собеседования. Задачи, вопросы и пункты знаний всё можно оценить, засечь время и оставить заметку.





  • Совместный кодинг в реальном времени. Удобная работа с задачами из списка: в один клик отправляешь в редактор, замеряешь время, оцениваешь.





  • Создание шаблонов для интервью разделы, вопросы, навыки, задачи.





  • Ну и собственно, отчёт: общий и по каждому разделу, задаче или вопросу.





Над текущим функционалом ещё нужно работать, но, я надеюсь, уже понятна основная концепция. Пока нет никакого бэка для хранения данных, всё храню просто в локалсторадж браузера. Под мобильные тоже пока сделал простой адаптив, для просмотра не вырви глаз, дизайн не продумывал.

Если кому-то интересно, пишу сервис на React, TypeScript, MobX.

Почему решил написать статью


Текущее состояние получилось за полтора месяца свободными вечерами после работы, потом, как это часто бывает, азарт куда-то улетучился и почти месяц я не трогал проект совсем.
Как мне кажется, сервис получается полезный и жаль его оставлять пылиться. Чтобы двигаться дальше, хочется узнать реальное мнение сообщества нужен он или нет. Т.к. это некоммерческий проект, такой способ самый реальный и точный, я думаю.

Над чем я работаю сейчас и какие фичи планирую внедрять:

  • Личный кабинет хотелось бы видеть как можно раньше.
  • Прокачать редактор кода
  • Отчёт о результате понятный и простой.
  • Запуск кода (пока только js и библиотеки).
  • Сгенерировать красивый фидбек на email кандидату.
  • Создание библиотеки вопросов, задач, навыков, чтобы можно было шаблоны собирать из готовых компонентов, в первую очередь, кастомных.
  • Удобство создания и работы с шаблоном (сортировка, редактирование элементов).
  • Добавлять метки о важности, времени, сложности и т.п. к вопросам/задачам.
  • Интеграция со своими сервисами и со сторонними (например, hh).
  • И в последнюю очередь, звонки из браузера.

и дальше ещё много мощных фич, колонка в трелло с ними очень высокая.

Конечно же под всё это дело в первых рядах будут задачи по созданию API.

В общем, попробуйте этот инструмент, если он вам покажется полезным. Я дождусь обратной связи, сделаю выводы и в случае положительной реакции форсированно буду воплощать свои фантазии и ваши рекомендации/пожелания.

А пока я буду допиливать текущее состояние.

beta.meet2code.com
Подробнее..

MVP на примере швейцарского ножа

04.06.2021 14:18:19 | Автор: admin

MVP (minimum viable product) - это первая версия вашего продукта, с помощью которой вы, как создатель продукта:

  • подтверждаете гипотезу о необходимости конкретного решения, опираясь на поведение пользователей;

  • собираете обратную связь от ваших будущих пользователей;

  • пытаетесь продать (или уже продаёте) ваше решение пользователям.

Пройдёмся по этим пунктам.

Возьмём в качестве примера не сложный IT-продукт, а самый обычный, бытовой предмет: швейцарский нож.

Однажды люди нащупали гипотезу, которая могла явиться проблемой: что если я оказываюсь в диком лесу, и мне нужно срезать гриб и отметить это, выпив бутылку шампанского? Носить с собой штопор и нож - попросту неудобно (да и кто в здравом уме берёт с собой в лес штопор?). Что, если объединить эти инструменты в одно?

Эти люди (назовём их фаундерами) попробовали совместить штопор и нож в одном инструменте, создали первый прототип (получилось криво и неудобно, но годно), и попытались продать будущим клиентам.

Представим, что у них это получилось. Что им делать в таком случае?

  1. продолжать продавать текущее решение, параллельно добавляя туда новые инструменты (функции), опираясь на обратную связь и пожелания покупателей;

  2. совершенствовать текущее решение, делать его более удобным (работать над UX);

  3. собирать обратную связь от пользователей и корректировать продукт.

Но всё получается с первого раза только у создателей швейцарских ножей. В реальной жизни 42% стартапов умирают от отсутствия спроса. Каждый раз фаундеры могут заходить на рынок с новым набором инструментов (пробовать разные гипотезы), либо, если всё идет наперекосяк - менять бизнес модель (сделать Pivot).

С каждой версией швейцарского ножа, нашим фаундерам нужно как можно быстрее выпустить образец на рынок, чтобы услышать обратную связь от покупателей.

Как это можно сделать?

  1. Производить и пытаться продать совсем маленькие партии;

  2. Экономить на качестве (но не так, чтобы получилось совсем плохо).

Именно такой подход: быстро создать решение, протестировать на пользователях, услышать обратную связь, и выйти на второй цикл улучшения продукта (или на смену бизнес-модели) и можно назвать MVP-подходом.

Как отбирать гипотезы и функции

Гипотеза - это предположение о проблеме клиента.

В одной версии продукта стоит тестировать только одну гипотезу за раз. При этом гипотеза должна быть смелая. Хотят ли люди есть грибы? Определенно да! Готовы ли пить шампанское? О да! Но может ли кому-то внезапно понадобится и нож, и штопор одновременно? Это уже гипотеза, которую стоит протестировать!

Теперь перейдём к тому, что можно включить в первую версию продукта. Ответ прост: нужно включать те функции, которые:

1) работают на проверку ключевой гипотезы. Не добавлять в швейцарский нож сам нож - кощунство;

2) дают наибольшую ценность для пользователя. Да, в швейцарский нож можно напихать ещё и трекер шагов, и bluetooth колонку, но основную ценность в нашем примере имеет нож и штопор.

Все функции, которые не удовлетворяют этим требованиям, можно смело оставлять на будущее.

Валидация без продукта

Можно ли подтвердить гипотезу относительно продукта, совсем не создавая никакого решения?

В IT-сфере - можно, если быть чуть хитрее и умнее, чем наши фаундеры из примера.

К примеру, они могли создать лендинг Чудо Швейцарские Ножи, повести на него трафик из социальных сетей, и посмотреть, оформляют ли люди предзаказ на этот товар. Если да - то его можно производить.

Примеров таких предзапусков в истории множество, но вот мой любимый:

Около 2-х лет создатели таск-менеджера Sunsama запустили на главной странице анкету, в которой опрашивали рабочие привычки будущих пользователей (сколько человек в команде, каким таск-менеджером пользуются сейчас, где хранят задачи и т.д.). Когда вышла первая версия продукта, доступ получили только те, кто подошёл в качестве целевой аудитории этого продукта. Таким образом создатели Sunsama убили трёх зайцев одним махом: исследовали аудиторию, получили первых последователей и подогрели интересы прочих, кто доступ не получил.

К слову, я даже пытался подобрать правильные ответы к анкете, чтобы получить доступ. И у меня это получилось! Но то, что оказалось внутри, мне уже было не интересно (не зря же я подбирал ответы).

Продавать или нет?

Автор книги Бизнес с нуля. Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели Эрик Рис говорит, что MVP с первого дня должен продавать. И я с ним абсолютно согласен.

Мы создаем продукты не только для того, чтобы решать проблемы и делать мир лучше, но и чтобы зарабатывать деньги. Если у вас есть инвестиции и собственные запасы, чтобы оплатить работу дизайнеров и разработчиков на долгие годы вперёд (чтобы впоследствии монетизировать платформу), это прекрасно. Если нет продукт должен начать приносить вам деньги уже сегодня (за счёт подписки на сервис, рекламы или взимания платы за интеграцию).

Ошибки при разработке MVP

MVP - это непаханное поле для больших ошибок и слитых бюджетов!

Вот какие ошибки вы можете совершить по ходу пьесы:

  • Включать слишком много необязательных функций. Представьте, что вы Роден (со швейцарским ножом в руке), и без сожаления выбрасывайте то, что не даёт ценности вашему продукту и не поддерживает его жизнеспособность;

  • Не слушать обратную связь от пользователей. Если вы не проводите тестирования и не слушаете обратную связь от пользователей, то вообще непонятно, зачем вы затеяли MVP. Возможно, вам стоит сразу пилить полноценный продукт и оказаться без миллиона в кармане?

  • Слишком стараться. Есть выражение, что если вы показываете первую версию продукта, и вам не стыдно - то вы уже перестарались. Поверьте, у вас будет бесконечно много шансов улучшить ваш продукт, и делать сразу идеально вовсе не обязательно!

  • Недостаточно стараться. Можно придумать отличную идею совместить нож со штопором, но если сделать это в стиле и таааак сойдёт!, то вы рискуете, что ваш пользователь окажется без руки, пользуясь вашим чудом техники. Перефразирую: в 21 веке уже недостаточно сделать косое и кривое приложение. Аппетиты и желания клиентов растут, поэтому постарайтесь, чтобы ваша первая версия выглядела хотя бы симпатично.

  • Влюбиться в продукт. Возможно, посреди разработки вам придется сменить концепцию. Возможно, вам придётся пожертвовать функциями, которые вам были так близки! А возможно, и весь продукт придётся прикрыть. Не влюбляйтесь в ваш продукт, иначе любые изменения будут даваться с трудом. Держите голову холодной, будьте гибкими, слушайте ваших пользователей. Помните, что подкидывать вам проблемы и задачи - это их основная работа.

Подробнее..

IT-инновации. Как внедрить и извлечь пользу

20.11.2020 00:18:43 | Автор: admin

В чем проблема?

Бизнес живёт в условиях гиперконкуренции. Новые предложения появляются на рынке ежеминутно и столь же часто меняются предпочтения потребителей. В этих условиях будет процветать бизнес, способный предлагать новаторские решения и системно совершенствовать продукт. Это современный путь к увеличению прибыли и привлекательности для инвесторов.

Инновации в широком смысле это научные открытия, новые технологии, применение новых подходов и методик, новые бизнес-модели, открывающие ценность, которая раньше была скрыта, новые рынки или даже новые сегменты пользователей.

Внедрение инноваций требует комплексного подхода, что ведет к издержкам. Многие бизнесы играют почти вслепую на этом поле, бездумно стараясь внедрить новомодные усовершенствования. Без грамотной стратегии и вложения средств внедрение новаторских решений может сыграть злую шутку.

Главная проблема здесь неопределенность, в которой действует бизнес.

Комплексный подход к внедрению инноваций

Эксперимент основной метод разработки и внедрения инноваций. Есть два способа разработки и планирования инновационных решений.

Customer Development - подход к созданию продукта или бизнеса, основанный на плотном взаимодействии с клиентом. Важным элементом является формулировка MVP (Minimum Viable Product) - минимального жизнеспособного продукта, обладающего минимальными, но достаточными для удовлетворения первых пользователей функциями.

В основе лежит формулирование и управление гипотезами. Гипотеза - предположение, которое основывается на том, что решение (продукт или сервис) принесет определенную ценность выделенному сегменту пользователей за счет удовлетворения потребности или решения какой-то проблемы. Гипотеза должна формироваться и проверяться на разных циклах Customer Development, но её конечная валидация происходит на этапе релиза MVP.

Ниже мы рассмотрим набор методов и инструментов, которые позволят значительно снизить порог входа в инновационную деятельность для среднего бизнеса.

Robotic Process Automation как пример инновационной ИТ-технологии

Robotic Process Automation - форма технологии автоматизации бизнес-процессов. Эта технология получила широкое распространение не только зарубежом, но и в России. Порой компании начинают внедрение там, где не стоит этого делать. Известны случаи, когда бизнесы вместо того, чтобы подготовить почву для внедрения RPA-решений и осмысленно подойти к вопросу, поспешно приобретают лицензии на готовые решения, либо инициируют разработку RPA-решений.

Одной из ошибок является неверное понимание того, какое место занимают элементы RPA в бизнес-архитектуре и ИТ-инфраструктуре. Робот не является частью инфраструктуры, а находится на более верхнем уровне в архитектуре бизнеса, взаимодействуя с интерфейсами существующих ИТ-приложений. RPA-решения насаживаются на существующую инфраструктуру, для того, чтобы выполнять рутинные операции, которые ранее выполнял человек. Чтобы понять, как внедрить RPA-решение и какие процессы можно отдать на выполнение этой технологии, нужно применить большой набор методик и инструментов.

Компоненты успешной разработки и внедрения инновационных ИТ-продуктов

Разработку и внедрение инноваций в бизнесе лучше рассматривать как стартап - автономное или полуавтономное подразделение, команду людей, наделенных свободой экспериментировать и несущих ответственность за результаты экспериментов. Важно не пытаться совмещать инновационную деятельность и операционное ведение бизнеса.

Технология Форсайт: анализ рынков, отраслей и выявление трендов.

Форсайт - технология средне- и долгосрочного прогнозирования, и оценки стратегических направлений развития, способных оказать воздействие на бизнес, экономику и общество. Это визионерский подход к стратегическому развитию бизнеса, который исследует драйверы, тенденции, факторы и кардинальные сдвиги в отраслях и рынках. Внедрение принятого решения может опираться на опыт и компетенции внутри компании. В случае, если бизнес не располагает таковыми, стоит посмотреть вовне.

Определение пользователей и требований.

Вне зависимости от того, является ли заказчиком бизнес, или внешний пользователь, акцент должен делаться на изучении конечного потребителя. Необходимо понимать какие пользователи будут и могут быть задействованы при работе с новой системой. Для выявления роли пользователей и составлениях их портрета используется Impact Mapping и интервью.

Impact mapping - это методика планирования для команд, которые создают ИТ-решения и продукты. Она основана на дизайне взаимодействия с пользователем, планировании, ориентированном на результат, и составлении диаграмм связей. Визуализация, помогающая составить портрет потребителя.

Основным инструментом выявления требований являются интервью. На начальных этапах возможна комбинация тех методик, которые используются в бизнес-анализе и так называемых проблемных интервью, предлагаемые методикой Customer Development. Далее, после того как ИТ-решение будет сформулировано, проводят решенческие интервью, целью которых является проверка правильности потенциального решения.

В случае, если понадобится применение технологии RPA, и решение будет внедряться для рынка B2B, то дальше необходимо придерживаться следующей последовательности относительно получения первых бизнес-кейсов (case study).

Анализ бизнес-процессов.

BPM (business process management) - концепция управления бизнес процессами занимает важное место в предлагаемом подходе. При создании ИТ-инноваций, тем более связанных с использованием RPA-решения, необходимо начать с описания основного и дополнительных процессов, в рамках которых работают все пользователи будущей системы.

Необходимо провести эти действия для пилотной имплементации решения, на основе которой будет описываться бизнес-кейс. Если имеется готовое описание бизнес-процессов, то на его основе можно произвести оценку для какой части бизнес-архитектуры целесообразно применение инструментов BPM, а для какой - RPA.

Далее, необходимо реализовать или обновить бизнес-архитектуру и выделить шаги для внедрения инновации. При этом надо фиксировать цели на каждом шаге процесса и метрики, которые будут отслеживаться. Один из инструментов, который может помочь в данном направлении - User Story Mapping - создание карты пользовательских историй, который строится на основе бизнес-сценария.

К robotic process automation прибегают именно на этой стадии, когда становится ясно, какие действия можно отдать на исполнение RPA-технологиям. В отличии от средств ИТ-автоматизации, RPA-решения способны адаптироваться к меняющейся среде, исключениям из правил и новым ситуациям. Эти самообучающиеся системы способны выявлять и интерпретировать действия в определенных процессах, оперировать данными, инициировать ответные действия, запускать команды и коммуникации с остальными системами в ИТ-инфраструктуре, и делать это автономно.

Инициативы, связанные с внедрением RPA-решений, просто не могут обойтись без управленческой концепции BPM. Особенно это важно для тех организаций, которые используют множество сложных систем, между которыми должен осуществляться бесперебойный обмен данными.

Формулировка гипотезы и описание MVP.

Сформулировать гипотезу означает описать сегмент пользователей, их проблему, что именно будет являться решением данной проблемы и показатели успешности MVP, т.е. метрики продукта. Для отслеживания метрик надо продумать и реализовать линейку - определить, как выбранные показатели будут отслеживаться, с помощью каких инструментов, кем и как часто. Результатом MVP являются знания и информация о том, подтвердилась ли основная гипотеза. Фокус нужно держать на целях, обозначенных на этапе анализа бизнес-процессов и метриках. Шаблон MVP позволяет наглядно представить всю эту информацию. Как следует и не следует подходить к формированию MVP я описал в этой статье.

Пример шаблона MVP

Для кого:

(пользователи системы)

Для администраторов и их менеджеров в среднем по размеру дата-центрированном бизнесе с географически распределенным оборудованием.

Которые:

(с какой проблемой сталкиваются или какую проблему пытаются решить)

Которые тратят много времени на то, чтобы предсказать и исправить сбои в оборудовании из-за отсутствия на рабочих местах или из-за того, что не знакомы с участком обслуживаемого оборудования (в случае, если это дежурный администратор).

Решение:

(предлагаемое нами инновационное решение проблемы пользователей)

Необходимо разработать мобильный интерфейс быстрого доступа к информации и функциям управления оборудованием, которое находятся в зоне риска, либо на которых уже случилась авария.

нность:

(как именно решим проблему пользователей и облегчаем им жизнь)

Данное решение должно уменьшить среднее время закрытия инцидентов и снизить частоту возникновения критических инцидентов за счёт проактивного подхода к работе с инцидентами и, как следствие, увеличить лояльность пользователей к продуктам компании.

В отличие от:

(дифференциация от конкурентов)

Решений X, Y, Z данный продукт будет иметь X, Y, Z особые функции

Опережающие индикаторы:

(метрики, значения которых важны при принятии решения об успешности MVP)

-Промежуток времени с момента возникновения инцидента до старта работ администратором.

-Время, которое тратит администратор на решение инцидента.

-Количество критичных инцидентов в системе в месяц.

Нефункциональные требования:

(требования к устойчивости, безопасности и т.д.)

-Система должна выдерживать нагрузку и обрабатывать X гигабайт данных в секунду.

скачать чеклист готовности MVP

В таблице приведен пример описания MVP системы мониторинга распределенной системы центров обработки данных, одним из элементов которой является RPA-технология (чат-бот) для оптимизации определенных процессов, связанных с администрированием оборудования.

User Story Mapping - создание карты пользовательских историй.

Этот этап позволяет правильно определить объем MVP для оптимального использования средств.

На данном этапе результаты проделанной работы - пользовательские истории, опережающие индикаторы, описанный процесс - сводятся воедино в карте пользовательских историй.

В данном примере на верхнем уровне (в блоках голубого цвета) находятся опережающие индикаторы, на которые новое решение должно влиять, уровнем ниже (в желтых блоках) - бизнес-процесс, в котором работают пользователи, разбитый на шаги, а ниже - расписаны минимальные решения, которые могут повлиять на каждую метрику в рамках каждого шага процесса.

При этом, данный инструмент дает возможность определять объем MVP, варьируя количество пользовательских историй, который влияют на опережающий индикатор. Количество функций, которые войдут в MVP, определяется горизонтальной линией, которая отделяет самые верхние минимальные пользовательские истории.

У будущего продукта может быть множество пользователей, и типичная ошибка на данном этапе - добавление и реализация всех функций для каждой роли пользователя. В этом нет смысла, поскольку создавать новый сервис или продукт, в котором будет множество разных функций для всех потенциальных пользователей экономически невыгодно.

  1. Запустить пилот и отслеживать метрики.

На этом этапе минимальный жизнеспособный продукт вводится в тестовую эксплуатацию и предоставляется первым пользователям, отслеживается, как работы, и исправляются обнаруженные дефекты. После того, как пользователи начали работать с системой (ИТ-решением, продуктом), и в системе появились данные, начинается работа с аналитикой - опережающими показателями.

Линейка, составленная на этапе формулировки гипотезы и MVP, предоставляет четкий и понятный инструмент для калибровки действий относительно дальнейшего развития продукта. Также, на этом этапе снимается и фиксируется обратная связь от пользователей.

В случае, если гипотеза подтверждена, после этого этапа повторяются подобные циклы работ, связанные с расширением функционала. Каждое последующее улучшение ИТ-решения проходит через цикл Разработать - Оценить результат - Сделать Выводы. Такой итерационный подход позволяет установить факты и соотнести свои предположения с действительностью. Поэтапное внедрение RPA-инноваций с помощью MVP позволяет постепенно уменьшать число операций, выполняемых человеком, тем самым снижать вероятность ошибки и повышать надежность решения.

Заключение

Инновации являются одним из ключевых факторов развития как частного бизнеса, так общества и государства в целом. Ранее компании концентрировались на повышении качества продукции и сервиса, вели ценовую конкуренцию. Современная действительность требует от бизнеса системного подхода к инновациям.

Корпорации уверенно осваивают и внедряют инновации. Для этого у них есть ресурсы и инфраструктура: собственные фонды и акселераторы, мероприятия, корпоративные школы, командировки во всея святых инноваций - Кремниевую долину. Как среднему бизнесу угнаться за передовиками инноваций и сохранить свою релевантность на рынке? Для тех, кто не в состоянии самостоятельно осилить данную инициативу предлагается начать с проведения форсайт-сессий или развивать партнерские связи в части разработки и управления инновационными ИТ-продуктами.

Консалтинг и проверка зарождающихся инициатив на прочность - один из способов решения этой задачи. Структурировать идею нового технологичного продукта или сервиса можно на воркшопе Проработка идеи ИТ-продукта и запуск валидации с помощью MVP.

Подробнее..

Цифровой акселератор СИБУРа приём заявок до 23 апреля

05.04.2021 14:09:20 | Автор: admin

Привет!

При поддержке GenerationS, платформы по развитию корпоративных инноваций, мы в СИБУРЕ запустили цифровой акселератор, призванный стартапам помочь пройти весь путь от MVP до конечного продукта в сотрудничестве с нами. У нас есть ряд цифровых инициатив, и нам нужны внешние команды, готовые их реализовать.

Что с нашей стороны? Самым успешным стартапам мы оплатим пилоты (до 0,5 млн рублей каждому), чтобы довести MVP до ума. Собственно, и поможем довести до ума за 3 месяца вместе с нашими экспертами. А потом представим те или иные решение (и команды) руководству СИБУРа на демо-дне, чтобы в будущем масштабировать продукт. Каждому проекту мы гарантируем трекерскую поддержку и возможность набраться отраслевой экспертизы.

Если ваш MVP успешно пройдёт пилотные испытание, то можно оформить с СИБУРом партнёрство.

Под катом все 10 направлений акселератора, требования к участникам и прочие формальности.

Disclaimer: Наш акселератор не является классическим в его понимании - учитывая требуемую скорость решения задач, мы изменили стандартный подход к участию в корпоративных акселераторах:

  1. Блок по упаковке проекта, который предусматривает работу с инвестиционной и бизнес-моделью, обучение и ряд других обязательных процедур, исключен. Это будет преимуществом для зрелых стартапов с готовыми продуктами и уже работающим бизнесом.

  2. Все 3 месяца разработки мы будем фокусироваться на доработке ваших существующих решений под задачи функциональных направлений СИБУРа. Основная business value или ценность для своего стартапа, которую участники получат это возможность оплачиваемой доработки своего продукта (до 500 тысяч рублей в зависимости от сложности доработок) под корпоративные требования крупнейшей нефтехимической компании совместно с функциональными заказчиками.

  3. Формат нашего акселератора это индустриальное партнерство: гибкость и применение принципов Agile в рамках реализации пилотных проектов вместе с отобранными командами. Мы надеемся, что такой практический опыт поможет стартапам не только более четко понимать требования к продукту (по функциональности, информационной безопасности и т.д.), которые являются обязательными для крупных промышленных компаний, но и применить в дальнейшем полученные знания при работе с другими крупными компаниями на рынке.

  4. В случае успешного пилотирования вас ждет зеленый свет и fast track с упрощением обязательных процедур при масштабировании инструмента на предприятия группы СИБУР. Это гораздо быстрее и эффективнее, чем если бы вы пришли в компанию без участия в корпоративном акселераторе.

Кого берём

Для участия в акселераторе нужно быть:

  • Технологической командой, у которой уже есть разработанный продукт или технология

  • Компанией, которая разрабатывает новые технологии

  • Стартапом

Важно, чтобы у вас была команда разработчиков, которая будет в состоянии адаптировать ваш продукт с учетом пользовательского опыта и особенностей нашей отрасли. Так что релевантный опыт в решении задач по направлениям акселератора тоже нужен.

А вот и направления.

Геймификация в корпоративном обучении

Вы наверняка проходили разные обучающие курсы на своих работах. Мы хотели бы сделать обучающий трек по-настоящему интересными и полезными, а не тем, что человек выполняет в последний момент после 10 напоминаний в почте. Тут потребуется создать игровую механику, которая будет развивать цифровой профиль сотрудника по результатам его тестов, пройденных курсов и вебинаров и решенных задач. Будет здорово, если эту геймификацию можно будет встроить в текущий личный кабинет сотрудника, который уже есть в СИБУРе.

Анализ договоров

Правовую экспертизу договоров можно автоматизировать. В разумных пределах. Например, на соответствие необходимым условиям договора и чек-листам, на нахождение разногласий в условиях, как смысловых, так и стилистических. Здесь же выдача отчётов в форме таблицы или текста.

Проведение ассессмента

Ассессмент это комплексная оценка персонала, ее хочется проводить в онлайн-формате, не только автоматизировав весь цикл оценки, но и давать рекомендации по развитию необходимых компетенций. Результатом хочется видеть веб-приложение или отдельное ПО.

Онлайн-конструктор корпоративных документов

Разные участники загружают в общее пространство некий неструктурированный контент. Из него нужно с помощью ИИ формировать единый документ, приведенный к шаблону из брендбука. Можно формировать такой документ и из загруженных презентаций. Пригодится встроенная библиотека шаблонов и тем.

Система удаленных инструктажей

У нас есть ряд инструктажей, которые хочется проводить удаленно на устройстве сотрудника по охране труда и по промышленной безопасности. Нужно реализовать идентификацию результатов каждого сотрудника в формате Сдал Не сдал, а информацию хранить, дабы выдавать пропуска в соответствии с пройденными курсами.

Робот-планировщик совещаний

Если вы назначали встречи коллегам через рабочий аутлук, то помните, каково там искать удобные по времени слоты для всех сразу. Даже при помощи планировщика. Тут хочется создать возможность автоматического подбора временных слотов в зависимости от занятости коллег с предзаполнением встречи в нашем корпоративном шаблоне. Реализовать в формате веб-приложения, адекватно работающего через браузер и с мобильного устройства. Делать самостоятельное мобильное приложение не нужно. Кстати, можно сделать и в формате надстройки для Outlook, если удастся реализовать всё так.

Система для отслеживания статуса обучения студентов

Студенты проходят обучение как в ВУЗе, так и участвуют на различных хакатонах, вебинарах и конкурсах, организованных компаниями на рынке. Поэтому необходимо структурировать данные по всем образовательным результатам. А потом создать цифровой профиль студента. Хочется видеть рейтинг и иметь возможность выгрузки. Возможно, имеет смысл сделать это в формате CRM, но тут уже дело ваше.

Система выявления потенциала сотрудников

Создание целевого профиля сотрудника (набор его качеств и компетенций), выявление на основе этого профиля потенциала сотрудника выдача рекомендаций по их развитию. Тоже можно сделать в виде CRM.

Онлайн-конструктор командных сессий

По запросу руководителей нужно автоматически формировать готовых программ командных сессий, основываясь на целях, задачах, количестве участников и формате мероприятия. Понадобится использовать типовые элементы: фреймворки, техники и инструменты фасилитации и модерации. Можно сделать как онлайн-сервис или же платформу для интеграции в существующие сервисы.

Инструмент анализа причин увольнения сотрудника

Формирование статистики и аналитики по увольнениям на основе анализа выходных интервью. Работник заполняет анкету с указанием причин, а эйчар получает уведомление с предложением провести экзит-интервью. Здесь тоже возможна CRM-механика, либо сделать робота, который будет собирать анкеты и назначать интервью.

Время

Тот самый демо-день с представлением вашего проекта руководству пройдёт 24 сентября 2021. А до него график такой:

  • до 23 апреля мы собираем ваши заявки на участие,

  • до 31 мая проводится их экспертиза,

  • 1 июня отбор проектов,

  • Со 2 июня по 6 сентября акселерационная программа.

И ещё немного формальностей

Возможно, у вас уже есть почти готовый проект по нашим направлениям, и часть информации под NDA. В таком случае при заявке на участие обязательно это учитывайте присылайте нам только те сведения о продукте, которые можете показывать в открытых презентациях.

Если у вас два проекта и хочется поучаствовать с каждым, дабы проверить шансы просто создайте на сайте второй профиль и подайте ещё одну заявку.

Подробнее..

MVP что это такое и как работает?

30.06.2020 12:04:28 | Автор: admin
Читая новости про новые проекты и сервисы, вы могли часто сталкиваться с понятием MVP. Но что скрывается под этой аббревиатурой и почему MVP так часто используют на начальных этапах развития продукта? Давайте прямо сейчас вместе разберемся в этом.

Что собой представляет MVP


image

Minimal Viable Product (минимально жизнеспособный продукт) тестовая версия товара, услуги или сервиса с минимальным набором функций (иногда даже одной), которая несет ценность для конечного потребителя.

MVP создают для тестирования гипотез и проверки жизнеспособности задуманного продукта, насколько он будет ценным и востребованным на рынке.

Результаты тестирования минимально жизнеспособного продукта и обратная связь от целевой аудитории помогают понять, стоит ли развивать проект дальше, какие изменения следует внести в стратегию, а что оставить в первоначальном виде.

Полезность разработки MVP доказывают примеры крупных на данный момент компаний. Например, Даниэль Эк и Мартин Лорентсон в 2006 году запустили небольшой сервис с одной функцией потоковая передача музыки. Сегодня их продукт Spotify оценивается в $21 миллиард, сотрудничает с крупными звукозаписывающими студиями и имеет 50 миллионов человек активной аудитории.

В 2008 году, когда аренда отеля или жилья во время путешествия была большой проблемой, два энтузиаста решили подойти к вопросу нестандартно и сдали свою квартиру по простому факсу. По сути, это тоже MVP, в котором тестировалась основная функция. Эксперимент показал, что продукт получит спрос, а сегодня Airbnb одна из крупнейших площадок по поиску краткосрочной аренды жилья.

MVP и PoC одно и то же?


Proof of Concept (PoC) доказательство правильности концепции и некоторые новички часто путают его с минимально жизнеспособным продуктом. PoC описывает процессы выяснения технической жизнеспособности концепции программного обеспечения (или любого другого продукта).

Да, эти определения взаимосвязаны, но не взаимозаменяемые. Proof of Concept описание процессов на начальной стадии развития продуктов, которые потом реализуются фактически, из чего получается MVP.

Виды MVP


image

Есть много разных подходов к созданию минимально жизнеспособного продукта, но на практике чаще всего используют некоторые из них. Далее поговорим о наиболее популярных.

MVP Флинстоуна


image

Помните, как в популярном мультике Флинстоуны глава семейства создавал иллюзию передвижения на автомобиле? Так вот, этот подход предусматривает имитирование наличия функционала, хотя на самом деле технически он никак не реализован. MVP нацелен на проверку гипотезы, доказательство жизнеспособности выбранной модели развития бизнеса.

Изначально у этого подхода было много критиков, мол, как можно что-то проверить, если ничего нет? Состоятельность метода доказал Ник Свинмерн основатель интернет-магазина Zappos, стоимость которого в 2015 году пробила отметку в $2 миллиарда.

Он сделал сайт и опубликовал фото разных моделей обуви. Получил заказ, пошел в магазин, приобрел нужную пару и отправил покупателю. Так он проверил жизнеспособность идеи продаж обуви через интернет, при этом изначально он не тратил деньги на аренду склада и закупку продукции, а лишь имитировал их наличие.

Консьерж MVP


Эта методология больше подходит для онлайн-сервисов, конечная цель которых автоматизировать решение проблем целевой аудитории. На начальных этапах реализации продукта услуга оказывается вручную.

Например, мы хотим сделать сервис по финансовому учету и планированию для физических лиц. Но чтобы проверить, будет ли пользоваться спросом эта идея, сначала сделаем несколько финансовых планов для клиентов вручную через Excel. Так мы сможем понять, кто и сколько готов платить, какие функции нужно реализовать в первую очередь и т.п. Часто консьерж MVP помогает в генерации новых идей, которые впоследствии делают конечный продукт лучше.

Эту модель в конце 90-х годов использовал Чак Темплтон основатель сервиса по онлайн-бронированию ресторанов, билетов и многого другого. Он не стал сразу вкладывать сотни тысяч долларов в техническую реализацию сервиса, а бронировал для других людей столики в ресторанах вручную. Так он проверил жизнеспособность идеи, понял, кто, сколько и за что готов платить и познакомился с целевой аудиторией.

Разрозненный MVP


Метод разрозненного MVP используют, когда идею можно проверить и реализовать без разработки уникального программного обеспечения. Вместо этого собирают готовые инструменты, объединяют в одну систему и преподносят в едином интерфейсе.

Если бы все компании начинались с разработки уникальных решений, которая обходилась бы в сотни тысяч долларов, мы бы не увидели много крутых проектов. К этому, как правило, переходят после запуска, получения обратной связи и первых результатов.

Посмотрите на популярный сервис совместных покупок Groupon. Когда-то он был простеньким сайтом на Wordpress, где все взаимодействие с пользователями осуществлялось по электронной почте. Только после получения первой обратной связи и финансовых результатов были разработаны социальные функции, полноценная email-рассылка, автоматизация и мобильное приложение.

Продукт с одним параметром


Эту разновидность используют чаще всего, когда есть готовый продукт с минимальным набором функций (как правило, одной). По такому принципу действовали основатели Spotify, которых упомянули в начале статьи.

Выпуск продукта с одной функцией (параметром) позволяет сузить целевую аудиторию, получить обратную связь и проанализировать ее, после чего приступить к тестированию.

Когда и для чего нужно делать MVP?


Приступайте к разработке MVP на начальных стадиях развития продукта. Идея может быть крутой только у вас в голове (да, такова уж суровая реальность), так зачем сразу вкладывать большие деньги в разработку, когда есть вариант с маленькими затратами и точной проверкой? После выпуска минимально жизнеспособного продукта вы определите спрос и поймете, в правильном направлении развиваете проект или нет.

Но самое крутое в MVP сбор ценной информации от первых пользователей. Именно конечный потребитель расскажет о правильной реализации проекта. Собранные данные используйте для планирования дальнейших обновлений и определения наиболее приоритетных целей: какие функции реализовать в первую очередь.

Как сделать MVP правильно


В теории вы узнали, что такое минимально жизнеспособный продукт, теперь поговорим о практической части создании MVP. Для получения хорошего результата разложите работу на мелкие итерации (шаги/этапы), обозначьте цели для команды в целом и задачи для каждого члена. Но в первую очередь донесите до коллектива общие принципы работы и создания продукта.

Нулевой этап: определяем основные принципы создания MVP


Проведите общее собрание коллектива, который примет участие в разработке MVP. На нем вы должны разобраться, все ли члены команды понимают, зачем это нужно. Обсудите видение минимально жизненного продукта, сложите все воедино и постройте первый примерный план дальнейшей работы.

В ходе общего собрания обсудите следующие вопросы:

  1. Как потратить минимум ресурсов? Помните, что на MVP должно быть потрачено минимум времени и сил. Вместе с командой разберитесь, как потратить мало денег, но при этом провести эффективное тестирование бизнес-идеи. Как правило, обсуждение этого вопроса помогает выбрать функции для реализации на начальном этапе развития продукта.
  2. Как взаимодействовать с пользователями? Одна из главных целей создания MVP тестирование гипотез, определение спроса и востребованности продукта. В этом помогает обратная связь от первых пользователей продукта. Чтобы не упустить ни капли важной информации, заранее продумайте все каналы взаимодействия с целевой аудиторией: отзывы, опросы, прямые интервью и т.п.
  3. Как сделать первые продажи продукта? Первые продажи продукта дадут средства для начала разработки и покажут, интересна ли кому-то разработанная концепция. Хороший вариант организовать сбор средств (предпродажи) на краудфандинговой площадке Kickstarter (международная), Boomstarter (Россия), Planeta (Россия) и т.п.
  4. Как будем продвигать продукт? На старте планируйте рекламную кампанию и используемые каналы. Основные инструменты контекстная реклама Яндекс и Google. Далее осваивайте социальные сети Facebook, ВКонтакте и Instagram. Создайте официальные страницы, запустите таргетинг. Кстати, брендированные сообщества один из каналов сбора обратной связи. Разработайте продающий лендинг: опишите продукт, расскажите о функциях, пользе для клиента, дайте пользователям возможность выбора между платной и бесплатной версиями продукта. После обсуждения этого вопросы вы должны знать, по каким каналам будете продвигаться и сколько денег потратите.

Постарайтесь привлечь к общему собранию максимум специалистов, чтобы рассмотреть идею и варианты тестирования с разных сторон. Обязательно составьте протокол собрания, в котором будут отражены основные мысли, идеи и принятые решения.

Первый этап: поиск проблемы, которую решит MVP


После определения основных принципов MVP, ответьте на вопрос: Какую проблему решает продукт?. Опишите его ценность в нескольких предложениях. Во-первых, это полезно для себя и команды, во-вторых, в дальнейшем поможет в создании уникального торгового предложения, лендинга и рекламной кампании.

Например, создаем сервис по финансовому планированию для физических лиц. Он решает проблему бесконтрольного расходования денежных средств, помогает организовать бюджет и ставить долгосрочные цели.

Второй этап: находим целевую аудиторию


Распространенная ошибка начинающих продактов и предпринимателей они считают, что их проект решает проблему широкой аудитории (всех людей). Такой подход в разы повышает вероятность провала. Сфокусируйтесь на определенной целевой аудитории.

Составьте портрет клиента, который обязательно купит продукт. Опишите его пол, возраст, социальное положение, уровень дохода, потребности, привычки, используемую им технику, распространенные проблемы, предпочтения в отдыхе и т.п.

Не торопитесь на этом этапе! Лучше потратить несколько часов для формирования портрета ЦА, чем потом слить весь рекламный бюджет и получить минимальную конверсию. И не забывайте про то, какую проблему решает MVP (это определяется на первом этапе).

Пример с сервисом по составлению финансовых планов для физических лиц:

  • 25-34 лет;
  • мужчины;
  • 40 000-80 000 рублей в месяц;
  • хотят погасить кредиты, накопить денежные средства, повысить качество жизни;
  • пользуются ПК и смартфон;
  • испытывают нехватка заработной платы до конца месяца.

Составлен примерный портрет, даже такой минимум позволяет ориентироваться и дает понимание, кому продаем продукт. Эта информация в дальнейшем поможет в организации рекламной кампании.

Третий этап: определяем основных конкурентов


Не думайте, что ваш продукт (идея) уникален и такого больше нигде нет. Если вы с ним не сталкивались лицом к лицу, это не гарантирует уникальность. И вообще есть гипотеза множественного открытия: все исследования и изобретения делаются сразу несколькими учеными независимо друг от друга.

Эту гипотезу подтверждает история с разработкой радио. В России считают, что его изобрел Александр Попов, а вот в Италии лавры отдают Гульельмо Маркони. Оба начали работать над реализацией идеи в 1894 году, но Попов свою разработку презентовал в марте 1896 года (но при этом не запатентовал), а Маркони в июне 1896 года подал документ на патент. Кстати, есть еще несколько ученых в разных странах, которые также претендуют на звание создатель Радио.

История с MVP аналогичная: вы должны потратить немало времени, но постараться найти конкурентов. Вам повезет, если идея все-таки окажется уникальной, а если нет, тогда решите следующие задачи:

  1. Соберите максимум информации об основных конкурентах. Проанализируйте трех самых крупных игроков рынка: изучите историю развития, посмотрите предлагаемые продукты, ознакомьтесь с конкурентными преимуществами и оцените способность предложить что-то лучше.
  2. Определите рыночные доли основных конкурентов. Рассмотрите деятельность компаний со всех сторон, определите их стратегии, объемы продаж, рассчитайте рентабельность и т.п. Так вы поймете, насколько они успешны и как можно опередить их в конкурентной борьбе (а главное, сколько на это придется потратить ресурсов).
  3. Изучите первичные источники информации. Все, что публикуют конкуренты о своей деятельности, первичные источники данных. Поэтому посмотрите их официальные сайты, презентации, белые книги, годовые отчеты, рекламные материалы и т.п. Это поможет разобрать деятельность конкурентов по кирпичикам и даст новые идеи для развития продукта.
  4. Изучите вторичные источники информации. Новости, видео, обзоры, интервью, оценки и т.п. вторичные источники информации. Их публикуют СМИ, независимые отраслевые сайты и многие другие. Сбор информации из вторичных источников поможет глубже понять выбранную отрасль и изучить правила игры. Но при этом не забывайте, что далеко не все дают достоверную информацию.
  5. Посетите отраслевые мероприятия. Ваши конкуренты презентуют продукцию или услуги на конференциях, выставках и любых других подходящих для этого площадках. Чтобы собрать максимум информации и задать интересующие вопросы, посещайте такие мероприятия. В большинстве случаев они бесплатны, поэтому потратить придется только свободное время.

В сборе информации помогут специальные аналитические инструменты: Similar Web, Ahrefs, Quantcast, App Annie, AppFollow и другие. Соберите данные о популярности конкурентов, ежемесячном трафике, основных интересах целевой аудитории, географическом расположении клиентов и т.п.

Для удобства советуем составлять сводную таблицу со всей собранной информацией. Впоследствии будет проще ориентироваться в больших массивах данных и принимать какие-либо решения.

Четвертый этап: проводим SWOT-анализ


SWOT-анализ представляет собой таблицу, состоящую из четырех блоков:

  • сильные стороны;
  • слабые стороны;
  • возможности;
  • угрозы.

Опять же, его лучше проводить коллективно или, по крайней мере, с основными членами командами. Важно объективно оценивать каждый пункт и не бояться признавать слабые стороны. Посмотрим реализацию SWOT-анализа на примере сервиса по финансовому планированию для физических лиц:

image

Не расписывайте пункты на целые абзацы. Они должны быть короткими и понятными для всей команды.

Обратите внимание, что таблица разделена на две части. Сильные и слабые стороны, как правило, относятся к внутренним факторам, а возможности и угрозы к внешним.

Цель SWOT-анализа выявить сильные стороны и возможности, чтобы сосредоточить работу на них для минимизации негативных последствий от слабых сторон и угроз. Сделанные выводы помогут выбрать стратегию развития и позиционирования бизнеса на рынке.

Пятый этап: создаем карту пути пользователя


Простой блиц для определения удобства продукта: если вы сами не понимаете, что надо делать с вашим сервисом (продуктом, услугой и т.п.), то потребитель разобраться точно не сможет!

Чтобы избежать такого недоразумения, на пятом этапе создания минимально жизнеспособного продукта составляют карту пути пользователя что делает пользователь при взаимодействии с продуктом. Вы должны понимать, какие у аудитории требования к контенту, дизайну, интерфейсу.

Кстати, не забывайте корректировать карту пути пользователя (user flow) после получения обратной связи от первых клиентов. Они расскажут, что хорошо, а что плохо или неудобно. На основе этого корректируйте карту, чтобы конечный потребитель получал то, что хочет.

Например, для сервиса по финансовому планированию сделали такую карту:

  • выбор периода планирования;
  • добавление активов, пассивов, доходов и расходов;
  • аналитика финансового плана;
  • постановка целей и отслеживание прогресса достижений.

Провели первые тестирования, за два месяца в поддержку написали несколько человек: у нас были финансовые планы в Excel, пришлось потратить часа два, чтобы все данные перенести в ваш сервис. Что делаем? Правильно! Добавляем функцию экспорта существующих в Excel финансовых планов.

Шестой этап: составляем перечень функций продукта


На прошлом этапе вы определили основные взаимодействия пользователя с продуктом, теперь для каждого опишите конкретные функции. Для удобства составьте специальную карту: взаимодействия и функции для каждого. Сначала она выглядит так:

image

Дальше для каждого взаимодействия определяется перечень функций. Здесь помогут логика и пользовательские истории. В первом случае самостоятельно или вместе с командой подумайте, что нужно сделать для обеспечения того или иного взаимодействия.

Но как вы помните, наше видение часто искажено, а вот реальные пользователи дают объективную информацию на основе опыта. Пользовательские истории описывают те или иные действия людей, на основе которых определяются необходимые функции.

Дальше расставьте все функции по приоритету. Самые востребованные (которыми пользуются чаще всего) ставим в начало списка, редко используемые в конец. Должна получиться вот такая карта:
image

Седьмой этап: определяем функции MVP


На этом этапе вы должны определить функционал MVP или иными словами запланировать объем минимально жизнеспособного продукта. Для начала определите несколько основных функций, без которых проект вообще не сможет существовать, от него не будет никакого толку. Это каркас или наименьшая полезная версия продукта.

Каркас как дом без отделки вроде бы, жить можно, но как-то не очень. Поэтому в большинстве случаев MVP дополняют разными полезностями. Для этого необходимо определить существенные и несущественные функции: какие нужны сейчас, а какие можно доработать потом в процессе развития проекта.

Опять же, классифицировать функции лучше коллективом. Обсуждения, споры, аргументация это приведет к определению оптимального объема минимально жизнеспособного продукта. На карте выделите каркас и дополнительные функции в рамках MVP для удобства дальнейшего планирования. Должно получиться что-то наподобие этого:

image

Такую карту с объемом минимально жизнеспособного продукта можно сделать на компьютере или на магнитной доске, стоящей в переговорной или аналогичном помещении. В ходе разработки допускается внесение корректировок.

Восьмой этап: выберите метод управления и разработки


Вы готовы к началу работы: определена идея, задачи, цели объем MVP. Осталось выбрать модель управления для достижения максимальной эффективности и соблюдения установленных сроков разработки. Возможно несколько вариантов:

  • Lean.
  • Scrum.
  • Канбан.
  • Экстремальное программирование (XP).

Этот этап один из важных. Можно придумать крутую идею, разработать качественный концепт, собрать команду высококлассных спецов, но если выберите неправильную модель управления, забудьте о достижении успеха. Поэтому хорошо подумайте, с какой системой работать в рамках реализации того или иного продукта.

Девятый этап: проводите тестирования


Тестируйте MVP короткими итерациями: альфа- и бета-тестированием. Альфа внутренний этап: закончили разработку, пользуйтесь продуктом внутри команды несколько дней. Если все окей, запускайте бета-тестирование внешний этап, дайте доступ к проекту первым пользователям. Длительность: 7-14 дней.

После первой беты соберите отзывы, статистику посещений, аналитику поведений и проанализируйте весь массив данных. Так вы узнаете, что надо доработать, что можно убрать, а что, наоборот, надо добавить в срочном порядке.

Несколько итераций разработка-альфа-бета помогут прийти к оптимальной первой версии продукта, который можно выпускать на рынок для массового пользователя и продолжать дорабатывать.

Еще раз поговорим всю последовательность этапов:

  1. Определение основных принципов создания MVP.
  2. Поиск проблемы, которую решит MVP.
  3. Поиск целевой аудитории.
  4. Определение и анализ основных конкурентов.
  5. Проведение SWOT-анализа.
  6. Создание карты пути пользователя.
  7. Составление перечня функций продукта.
  8. Определение объема MVP.
  9. Выбор метода управления и разработки.
  10. Проведение тестирований.

Пройдя 10 этапов, вы получите хороший минимально жизнеспособный продукт, который впоследствии перерастет в первую версию полноценного проекта. И не бойтесь вносить правки: отказываться от каких-то этапов, добавлять собственные и т.п. Данная последовательность шагов не строгое правило, а лишь пример или образец, на основе которого вы можете построить что-то собственное и уникальное.

Самые распространенные ошибки при создании MVP


Теперь вы знаете, как создать свой MVP. Но есть еще один момент: новички (им это простительно, кстати) часто допускают ошибки при планировании первых минимально жизнеспособных продуктов. На второй-третий раз, набравшись опыта, они работают быстрее и эффективнее.

Но зачем учиться на собственном опыте, когда есть чужой? Почему бы не использовать его и постараться избежать неточностей на своем пути? Поэтому далее поговорим о самых распространенных ошибках начинающих продакт-менеджеров и предпринимателей.

Попытки достигнуть идеала


Закройте в клетке своего перфекциониста, потому что в ходе разработки MVP он сыграет с вами злую шутку! Запомните, задача минимально жизнеспособного продукта дать пользователю базовое представление о продукте, он априори не должен и не может быть идеальным.

Вы тестируете гипотезу! Поверьте, маленького MVP хватит для определения потенциала идеи. Если она крутая, то спрос на продукт не испортит даже плохой дизайн, интерфейс и минимальная скорость работы. И только при подтверждении этой гипотезы начинайте тратить ресурсы на юзабилити и красивый фантик.

Небрежная работа


Если MVP не должен быть идеальным, это не значит, что его можно делать, как попало. Некоторые продакты бросаются из крайности в крайность, в результате получает вообще что-то непонятное.

Минимально жизнеспособный продукт должен быть простым, но качественным. Например, если делаете сервис, то купите хотя бы домен второго уровня, не надо оставлять его на поддомене какого-то бесплатного конструктора.

Отсутствие обратной связи


Некоторые новички так увлекаются разработкой, что забывают о приоритетной цели сборе обратной связи. Еще на стадии планирования следует определить ключевые метрики, которые покажут успешность проекта. Это может быть количество скачиваний или покупок, число новых пользователей, коэффициент удержания клиентов и т.п.

Пустые обещания


Когда глаза горят, есть ощущение способности свернуть горы! И в такие моменты руководитель начинает делать анонсы крутых и необычайных возможностей. Конечно, это все здорово с точки зрения маркетинга, но если не сдерживать обещания, пользователи начнут покидать проект.

Поэтому всегда принимайте решения о новых анонсах на холодную голову. Объективно оценивайте, что сможете сделать, а что нет.

Отказ от анализа и аналитики


Окрыленность собственной идеей часто дурманит разум и вся команда перестает обращать внимание на объективные факты: плохие метрики, отрицательные отзывы и т.п. Начинают думать, что просто пользователи не все понимают сейчас, а вот когда финальная версия продукта будет готова, тогда они оценят.

Нет, не оценят. В этом деле всегда важен объективизм. Есть обратная связь от реальных пользователей, слушайте ее, корректируйте работу проекта в соответствии с желаниями конечных потребителей, иначе во всей этой суете нет никакого смысла.

Итак, подведем краткий итог: MVP минимально жизнеспособный продукт, который делают для тестирования идей и гипотез, сбора обратной связи от первых потребителей (и да, MVP PoC). Реализовать можно за 10 этапов и постараться избежать наиболее распространенных ошибок. Если вы планируете создание нового продукта, начинайте с MVP: это позволит избежать больших ресурсных потерь в случае плохого потенциала идеи.

Ещё больше о MVP можно узнать на нашем годовом курсе Профессия: Продакт (с 0 до PRO) Узнать подробности

Подробнее..

Recovery mode Техника определения MVP

02.07.2020 12:23:15 | Автор: admin

Привет!


Ниже по тексту предлагаю ознакомится с подходом, который я применяю для определения функциональности, которая должна войти в MVP для продуктов с достаточной степенью определенности в бэклоге. Если зайдет, распишу подробнее. Прошу не судить строго, но буду рад конструктивной критике.


Для всех кто готов мирится с сыроватостью идеи, добро пожаловать под кат)


Введение


Задача определения функциональности MVP появляется еще на этапе планирования разработки продукта и требует обновленного решения по мере развития продукта, вплоть до окончания разработки MVP.


Сама концепция MVP предполагает как можно более быструю доставку продукта конечным пользователям для получения от них обратной связи, однако собственники продуктов (Product Owner) зачастую превышают минимальную функциональность стремясь сделать продукт лучше, что влечет за собой срывы сроков, превышение бюджетов, а в худших случаях и вовсе развитие продукта в неправильном направлении.


Для нивелирования вышеупомянутых рисков предлагается использовать конкретный подход, основанный на математических принципах, для регламентирования процесса определения функциональности MVP.


Критерии


Критериями для задачи определения MVP функциональности являются критерии, взятые из методологии WSJF а также дополнительная декомпозиция Job Duration на составляющие:


Cost of delay


  • User-Business Value: Насколько громко просят об это пользователи? Как это отразится в деньгах, если эта штука НЕ будет сделана? Какой потенциально негативный эффект будет, если это выполнить позже, а не раньше?
  • Time Criticality: Как это влияет на общий поток поставки? Задерживает ли реализацию чего-то еще? Нужно ли это выпустить к определенной дате? Есть ли риск того, что опоздание с этим умножит на ноль весь смысл проделанной работы?
  • Risk Reduction: Снижает ли это какие-то риски? Будет ли это позитивно влиять на качество в других областях? Будет ли эффект сиюминутным или долгосрочным?
  • Opportunity Enablement: Откроет ли эта штука новые возможности для продукта или всего бизнеса? Поможет ли выйти на новые рынки сбыта/привлечь других клиентов?

Job Duration


  • Job Duration Оценка времени на реализацию, производится по предварительному анализу Features с участием Тех Лидера команды разработки или Архитектора. Выполняется верхнеуровнево, без декомпозиции Features на более низкие уровни
  • Job Complexity- Оценка сложности реализации, выполняется совместно с Тим Лидером команды разработки индивидуально, с учетом опыта и навыков команды, которая работает над данным продуктом. Данная оценка также включает в себя оценку степени неопределенности Features, которая в свою очередь прямо пропорционально влияет на сложность этих самых Features.
  • Job Cost Оценка стоимости реализации, высчитывается исходя из необходимых человеко-часов на определенную задачу, и перемножения его на стоимость человеко-часа в команде. Данная оценка является относительной и не подлежит для использования в расчетах стоимости реализации продукта, и нужна только для приоритизации бэклога.

Процесс оценки


Оценка выполняется с помощью числового ряда Фиббоначи от 1 до 21. (1, 3, 5, 8, 13, 21). Данный способ оценки универсален с точки зрения использования его при оценке задач в Story Points при планировании, и для групповой оценки критериев также возможно использования Scrum-poker.


Также, оценка с помощью ряда Фиббоначи обусловлена тем, что каждый шаг значений увеличивается не линейно, а значит будет сложнее сложить все в одну оценку. Так же чувствуется разброс, например сразу видна разница в бизнес ценности между задачей в 3 и 21 Story Points.
Оценки по критериям из группы Jobs Duration выполняются командой разработки, а оценки по группе критериев Cost Of Delay только с привлечение бизнес-заказчика и Владельца Продукта.


Итогом оценки будет матрица следующего вида:




Сведение задачи определения MVP к решению задачи многокритериальной оптимизации.


Многокритериальная оптимизация, или программирование (англ. Multi-objective optimization) это процесс одновременной оптимизации двух или более конфликтующих целевых функций в заданной области определения. Наиболее простым способом решения задачи многокритериальной оптимизации является метод Свертывание критериев, для сведения многокритериальной оптимизации к однокритериальной. Метод свертывания критериев предполагает преобразование набора имеющихся частных критериев в один суперкритерий. Т. е. мы получаем новый суперкритерий, который является функцией от частных критериев.


Для свертывания критериев в суперкритерий необходимо также проставить весовые коэффициенты:



Для бизнес критериев и критериев разработки необходимо устанавливать отдельные весовые коэффициенты.


Таким образом свертывание критериев будет выглядеть следующим образом:


Cost Of Delay = User-Business Valuek11+ Time Criticalityk12+ Risk Reductionk13+ Opportunity Enablementk14
Jobs Duration = Job Durationk21+ Job Complexityk22+ Job Cost*k23
K11+K12+K13+K14=1
K21+K22+K23=1
Общий критерий оптимизации (Mutual Criteria) = Cost of Delay/Jobs Duration.


Таким образом мы получаем матрицу следующего вида:



Итоговой целевой функцией является Максимизация по Mutual Criteria.


Определение MVP Функциональности с помощью ABC анализа.


ABC-анализ метод, позволяющий классифицировать задачи по степени их важности. Этот анализ является одним из методов рационализации и может применяться в сфере деятельности любого предприятия. В его основе лежит принцип Парето 20 % всех усилий дают 80 % результата. По отношению к ABC-анализу правило Парето может прозвучать так: 20% функциональности позволяет покрыть 80 % потребностей пользователей.


ABC-анализ анализ бэклога (набора Features) путём деления на три категории:


А наиболее ценные, 20% от количества; 80% удовлетворения потребностей
В промежуточные, 30% от количества; 15% удовлетворения потребностей
С наименее ценные, 50% от количества; 5% удовлетворения потребностей


Группа А является группой функциональности входящей в MVP.


По сути, ABC-анализ это ранжирование бэклога по разным параметрам. Результатом АВС анализа является группировка объектов по степени влияния на общий результат.


АВС-анализ основывается на принципе дисбаланса, при проведении которого строится график зависимости совокупного эффекта от количества элементов. Такой график называется кривой Парето, кривой Лоренца или ABC-кривой. Таким образом, 20% функциональности, закрывают 80% потребностей. Исходя из данного принципа, производим АВС анализ для бэклога, для определения MVP.


Для этого:


  1. Определяем цель анализа Ранжирование Бэклога для определения первых 20% функциональности, из которой будет сформирован MVP.
  2. Объект анализа Набор Features из бэклога.
  3. Берем перечень функциональности, ранжированный по многокритериальной модели (MC).
  4. Разделяем ранжир на 2 класса первые 20% (A), оставшиеся 80% (B+C).
  5. Первый класс (A) определяет MVP.

Важное замечание: Необходимо также учитывать CORE функциональность. Группа А может совпадать c CORE, но в случае не совпадения, результаты АВС анализа должны быть дополнены Core функциональностью.


CORE функциональность это основа функционирования продукта, которая состоит из функциональности, без которой функционирование продукта невозможно. (Например, авторизации).


Выводы


Применение данной методики для определения набора Features для MVP обеспечивает обоснованный выбор рационального количества задач, необходимых к выполнению для скорейшего достижения MVP.

Подробнее..

Материалы с митапа для аналитиков роль аналитика в развитии продуктов

26.03.2021 16:04:17 | Автор: admin

Недавно прошёл наш митап для аналитиков, а значит, пора делиться презентациями и видеозаписями выступлений. В них спикеры из Skyeng, Ситимобил и Авито на боевых примерах показывают пользу аналитики для запуска, тестирования и развития продуктов.

Поиск точек роста в продукте с помощью аналитики на примере Избранных продавцов Иван Жучков, Авито

Авито позволяет подписаться на интересующих вас продавцов. Иван рассказал, как аналитика помогала масштабировать и развивать этот продукт и каких результатов удалось достичь.

00:00 Представление спикера и плана доклада

01:08 Продукт: Избранные продавцы

02:16 Стартовые метрики и первые проблемы с ними

04:13 Рекомендации подписок на продавцов

08:10 Воронка продукта и инициативы из неё

11:13 Применение анализа поведения пользователей

13:54 Сравнительная ценность подписок на продавцов

16:31 Итоговый рост метрик продукта

17:41 Ответы на вопросы

Посмотреть презентацию Ивана

Оценка потенциала кикшеринга в сервисе Ситимобил Андрей Лекомцев, Ситимобил

История о том, что такое кикшеринг, зачем он нужен такси, и как Ситимобил через аналитику пришёл к тому, чтобы его интегрировать.

00:00 Представление спикера и темы

00:30 Проблемы руководителей проектов и воронка продуктовой фичи

02:32 Что такое кикшеринг и в чём его особенности

04:25 Оценка задачи по интеграции самокатов

09:40 Как использовали результаты

10:20 Ответы на вопросы

Посмотреть презентацию Андрея

Аналитика в продуктовой разработке на примере Автопубликации объявлений Мария Перетрухина, Авито

Мария рассказала о пути создания инструмента для автоматического продления объявлений. Из доклада вы узнаете, какую проблему мы хотели решить, как проверяли гипотезу, как оценивали риски и какие результаты получили.

00:00 Представление спикера и план доклада

00:43 Проблема: упущенный контент в объявлениях

04:12 Оценка потенциального прироста базы контента

05:33 Поиск решения: как терять меньше контента

07:07 Проверка гипотезы с помощью MVP

10:30 Многоразовая автопубликация: оценка и предотвращение рисков

17:35 Результаты внедрения Автопубликации

20:46 Ответы на вопросы

Посмотреть презентацию Марии

Поиск точек роста в новом продукте с помощью алертов Михаил Михайлов, Skyeng

При запуске нового продукта, сервиса или фичи хочется, чтобы они выстрелили. Для достижения поставленных целей компании используют разные инструменты и подходы. Михаил поделился кейсом внедрения такого инструмента, который помог забустить рост продукта.

00:00 Представление спикера и темы

01:57 Skyeng до нового продукта

04:06 Идея нового премиум-продукта и поиск составляющих для него

10:13 Внедрение алертов

15:49 Как устроена работа с алертом: кейсы из практики

21:51 Выводы: как аналитик может помочь продукту выстрелить

22:48 Ответы на вопросы

Посмотреть презентацию Михаила

На сегодня всё. До встречи на новых митапах!

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru