На хабре при желании (или даже без него) можно найти не один пост, посвященный стартапам. Однако, для «долгой и счастливой жизни» качественного стартапа недостаточно. Другими словами, после выпуска первой версии проект должен продолжать развиваться. А значит, должны выходить новые версии.
Очевидно, что для коммерческого успеха новая версия должна быть «лучше» предыдущей. С другой стороны, практика показывает, что для разработчиков и пользователей термин «лучше» далеко не всегда означает одно и то же.
Мне «посчастливилось» совмещать работу разработчика и менеджера по проекту. Другими словами, я не только пишу код, но и решаю, что необходимо изменить/добавить/удалить. Причем тонкостям последнего пришлось учиться «на ходу», анализируя успехи и ошибки своих коллег. Собственно, этим наблюдениям я и хочу посвятить статью.
Я пришел к выводу, что новая версия проекта будет успешной, если она удовлетворяет двум требованиям:
- Пользователь найдет в ней изменения, которые он ожидает
- Пользователь не найдет в ней изменений, которых он не ожидает
Изменения, которые пользователь ожидает
Их можно классифицировать на два типа:
- Исправление ошибок
- Новые возможности
Казалось бы, тут все просто. Но эта простота рушиться, когда возникает проблема со сроками и встает вопрос: «Исправлять оставшиеся ошибки или добавлять новые возможности?». Однозначного ответа дать не получается. Конечно, перфекционисты скажут, что необходимо исправлять ошибки. Однако рынок говорит, что деньги люди будут платить за новые функции. В качестве наименьшего из зол, можно нужно первым делом исправлять критические ошибки, а потом стараться добавить новые функции без добавления новых ошибок. Все остальное можно исправить с помощью хот-фиксов и патчей, хотя это и не слишком «красиво». В моем случае выбор именно этой стратегии дал наилучший результат.
Изменения, которые пользователь не ожидает
К сожалению, порой разработчики случайно (или умышленно) забывают об этом пункте. Причина этого может быть в том, что они стараются привлечь новых пользователей. Однако, не стоит забывать о том, что успех новой версии ПО во многом зависит и от того, приобрели ли его пользователи предыдущих версий. И именно для них подобные изменения могут оказаться критическими.
Список типов таких изменений может быть очень большим, я же остановлюсь на двух:
- Обратная совместимость
- Изменение дизайна
Обратная совместимость очень важна. Люди, которые использовали ваш продукт годами (почему бы и нет) будут весьма «обескуражены» узнав, что новая версия не способна работать с их проектами. Таким образом, можно говорить, что вы их потеряете.
А вот с изменением дизайна все не так просто. С одной стороны, менять его надо. Время идет, технологии меняются и дизайн «привет из 1999» уже не популярен. С другой стороны, практика показывает, что многие пользователи очень консервативны. Они способны очень болезненно переживать из-за «пропавшей кнопочки вот тут, в углу» или даже из-за изменения цветовой схемы. Поэтому весьма неплохим решением будет добавить галочку «old-style» где-нибудь в настройках.
Заключение
Конечно, проблем на самом деле много больше. Я лишь постарался описать те из них, с которыми столкнулся сам. Возможно, если и более серьезные проблемы или надежные решения — я бы с радостью про них послушал.
В качестве руководства к действию хочу добавить следующее. Не стоит считать пользователей простаками, если вы не Стив Джобс. Лично я выбрал подход «пользователь знает, чего он хочет, но не может этого объяснить». На данный момент и я, и начальство результатами подхода довольны.
Автор: Leproza
