snake_d_ha (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
snake_d_ha) wrote2018-10-02 07:52 pm
snake_d_ha) wrote2018-10-02 07:52 pm
Как сделать плохую программу
Этой осенью у меня развлечением идут курсы бизнес-анализа.
Сегодня была первая большая практика, которая полностью подтвердила то, что я подозревал и обычно видел в качестве результата с противоположной стороны, заказчика и пользователя.
Вводная:
Приложение CarWash, которое дает возможность выбирать и бронировать мойку для авто среди многих разных моек. Нужно от разработчика определить основные фичи, ценность для клиента и потребителей, сделать план работ и набросок контракта с производственной стороны.
По ходу подбрасывали вторичные данные, типа портретов пользователей или контекста дат разработки.
Сделаете прогноз основных фич и пользователей по результатам трех часов работы не самых глупых людей из ИТ? :)
Итак, приложение должно:
1. Делать поиск по параметрам.
2. Вести рейтинг.
3. Информировать о том, какие услуги на мойке есть и почем.
4. Давать возможность бронировать.
5. Давать возможность платить и вести платежи.
6. Давать уведомления о состоянии мойки и ее окончании.
7. Вести программу лояльности.
И основными пользователями у нее заказчик, администратор и мойщик. Бухгалтера я из пользователей вынес, буквально ложась костьми.
И все равно получилось недо-ERP без кассовой части, вместо обычного интерактивного календаря бронирования. Где-то после завершения стартового запала, на первой попытке взять за нее деньги все закончится.
Бизнес-аналитику вместо развешивания фич нужно было повертеть пальцем у виска и сказать идеологам (конечно, к клиентам они отношения не имели), что либо мы делаем независимый рейтинг и поиск, либо мы получаем данные о свободных местах и изменении цен от какой-то одной сети для записи к ним и продвижения.
Или мы делаем таки отраслевую ERP на базе крупного клиента с надеждой продавать ее потом разной мелочи, что уже вообще другая история.
Все три варианта имеют свои недостатки, но о них по крайней мере можно говорить серьезно.
А то, что получилось - типичный стартап. Вот откуда они возникают, оказывается!
Сегодня была первая большая практика, которая полностью подтвердила то, что я подозревал и обычно видел в качестве результата с противоположной стороны, заказчика и пользователя.
Вводная:
Приложение CarWash, которое дает возможность выбирать и бронировать мойку для авто среди многих разных моек. Нужно от разработчика определить основные фичи, ценность для клиента и потребителей, сделать план работ и набросок контракта с производственной стороны.
По ходу подбрасывали вторичные данные, типа портретов пользователей или контекста дат разработки.
Сделаете прогноз основных фич и пользователей по результатам трех часов работы не самых глупых людей из ИТ? :)
Итак, приложение должно:
1. Делать поиск по параметрам.
2. Вести рейтинг.
3. Информировать о том, какие услуги на мойке есть и почем.
4. Давать возможность бронировать.
5. Давать возможность платить и вести платежи.
6. Давать уведомления о состоянии мойки и ее окончании.
7. Вести программу лояльности.
И основными пользователями у нее заказчик, администратор и мойщик. Бухгалтера я из пользователей вынес, буквально ложась костьми.
И все равно получилось недо-ERP без кассовой части, вместо обычного интерактивного календаря бронирования. Где-то после завершения стартового запала, на первой попытке взять за нее деньги все закончится.
Бизнес-аналитику вместо развешивания фич нужно было повертеть пальцем у виска и сказать идеологам (конечно, к клиентам они отношения не имели), что либо мы делаем независимый рейтинг и поиск, либо мы получаем данные о свободных местах и изменении цен от какой-то одной сети для записи к ним и продвижения.
Или мы делаем таки отраслевую ERP на базе крупного клиента с надеждой продавать ее потом разной мелочи, что уже вообще другая история.
Все три варианта имеют свои недостатки, но о них по крайней мере можно говорить серьезно.
А то, что получилось - типичный стартап. Вот откуда они возникают, оказывается!