Как стать автором
Обновить

Почему профессионалы своего дела порой создают плохие приложения?

Время на прочтение 3 мин
Количество просмотров 2.6K
Всего голосов 17: ↑6 и ↓11 -5
Комментарии 15

Комментарии 15

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

Где-то в этом тексте пропущено слово минимально жизнеспособный продукт, который клепается как попало на коленке из готовых решений, и на котором проверяются все идеи, а уже потом, собирается та самая команда «талантливых и профессиональных специалистов» с кучей времени и бюджетом на разработку и дальнейшее развитие всего «как полагается». В такой цепочке вероятность долго делать что-то большое и ненужное резко снижается.
Согласен. Я долго думал, включать ли MVP в статью или нет. Но я подумал о том, что если проект является каким-то замороченным SaaS сервисом или маркетплейсом, то для него нужно все равно создать набор каких-то фич. А это потянет на себя и время и бюджет. Как тогда создать минимально жизнеспособный проект в таком случае, я не придумал, к сожалению.
НЛО прилетело и опубликовало эту надпись здесь
При общении бизнес аналитика с заказчиком был сформирован достаточно большой пакет документации, который впоследствии был переработан в подробное техническое задание (далее ТЗ).

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

Согласен, я бы ещё добавил следующее предложение:


По этому ТЗ были рассчитаны эстимейты и дедлайны для каждого этапа работы.

Это "водопад", а не "спираль". Если заказчик и исполнитель профи (как указано в условиях), то явно всю жизнь сидели на госзаказах. А раз так, то конечный результат никого не волнует. Главное, что всё выполнено согласно ТЗ и в заданые сроки.

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

Ну, и не забываем Бонапарта: Лучше лев во главе стада баранов, чем баран во главе стада львов.
НЛО прилетело и опубликовало эту надпись здесь
Не, ну ладно, мвп действительно не всегда и везде есть и возможен, но вроде как есть же какие-то гайдлайны по UX. Если у компании отличные UI/UX дизайнеры, то поидее таких проблем же быть не должно? Попровьте, если я не правильно понял
UI/UX дизайн правильная и нужная вещь. Но есть достаточно большое количество сайтов, где вообще нет никакого дизайна, но ресурс востребован. И наоборот, есть супер дизайн по всем канонам UI/UX, а проект не востребован. И тут вопрос, а в дизайне ли дело. И если и в нем тоже, то сколько процентов он имеет в финальном результате от всего проекта?
Здесь, судя по тексту, представления о потребностях пользователей были ошибочны.

Описанная в кейсе не имеет отношения к команде разработчиков.


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

Я знаю эти проекты: «Госуслуги», «ЛК налогоплательщика», «Электронный дневник»!
>> А вы как считаете, как же нужно было правильно все строить, чтобы не получить в итоге нечто, никому не нужное?

Нужен был ещё один профессионал. Но куча профессионалов в других областях решила, что они знают достаточно. Стандартная проблема междисциплинарного решения.
А вы как считаете, как же нужно было правильно все строить, чтобы не получить в итоге нечто, никому не нужное? Свои предложения пишите в комментариях.
Прежде всего желание сделать качественный продукт. Качественный продукт прежде всего обеспечивается глубиной проработки мелочей, подгонка и модификация его под текущие варианты использования.
Качественный продукт вряд ли может быть результатом работы только одного человека, для этого нужна команда. Применение сильных сторон каждого из членов команды сформирует синергетический эффект, как по мне это базис для продукта.
Есть такая штука — прототипирование. Странно, что команда супер-профи не представила заказчику прототип, а ломанулась реализовывать все его желания. Для любых webapp? приложений, даже некоторых сайтов нужен прототип. Делается это на коленке и достаточно даже бесплатного приложения pensil
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории