Идея в том, что от лозунга «Делаем быстрый плохой релиз» переходим к «Делаем продуманный и дешевый релиз» (и пошагово расписано как это сделать). Про почему и зачем, если есть деньги на быстрый и доработки после него, можно отдельную заметку написать. А если денег на проект немного, то и рассуждать особо не о чем.
Ориентация, скажем, на то, что обычно появляется в блоге «Я пиарюсь».
Ваши подходы так же важны, но они более дорогие и дополнительно покрывают более тонкие моменты, т.е. можно просто позже применять. Тут же важно добиться приемлемости результата первого релиза, т.е. чтобы им пользовались и за него платили деньги (по сути проверка идеи стартапа на прототипе). А потом уж, как у любого успешного сервиса, бесконечные доработки для увеличения пользовательской базы и прибыли.
С преждевременным подключением программистов одна идея: выпустить первый релиз быстрее. Это получается за счет качества продуманности релиза. Потом идут исправления и «как же мы об этом сразу не подумали». Именно на этом моменте можно сэкономить приличное кол-во денег. Особенно, если у вас уже есть явные конкуренты и рынок не пустой.
Спасибо за ссылку. Balsamiq (по блогу) делают веб-версию своего творения (не только как демо), может через полгодика увидим. По ui показалось похуже Balsamiq, но пока что бесплатно.
Сценарии использования — положительно.
Динамический серверный прототип (не просто хтмл/css/js) — отрицательно, если это не обкатка какой-нибудь новой для команды программистов технологии (отдельный вопрос, здесь не касаемся).
Все примерно как у вас, только программисты подключаются после дизайна и юзабилити тестирования. До этого верстальщики максимум. Почему так? Большинство стартапов не являются технически сложными, сомнений что это можно реализовать нет. Вопрос именно в пользователе: будет пользоваться или нет, будет платить за сервис (так или иначе) или нет. Дополнительно, программисты дороже, поэтому желательно, чтобы у них было меньше часов и меньше переделок.
С другой стороны, если вы, например, делаете систему распознания голоса, то дизайн после (если не нужно привлекать инвестиции), сначала должно нормально заработать распознание.
Если серьезно, то, цитата из разговора в «аське» об этой статье:
Пост из разряда все знают, но никто не выполняет почему-то
а потом: ну отчего же ничего не получилось
Я с ней согласен: just do it, пошагово. В своей практике, к сожалению, этого не наблюдаю (что люди кроме того что знают еще и делают, а новички еще и не знают).
И да, книги «Getting Real», «Rework» и «Дизайн пользовательского интерфейса II. Искусство мыть слона» рекомендую.
Это не конкретный success story. Возможно, через несколько месяцев так или иначе опубликую результаты ее сознательного применения (сейчас по ней делаю несколько проектов).
Схема же выработана на основе предыдущего личного опыта. Практически во всех прошлых проектах она бы принесла ощутимые результаты.
Не вижу причин не придерживаться плана в целом, кроме лени. Естественно, что-то из-за реальной жизни будет несколько меняться, но схему в общем и этапность имеет смысл сохранять. Причем, подобный план может предлагать как заказчик, так и исполнитель (т.е. тестирование и ui делает дизайнер, а не команда стартапа).
Думаю, что исходный проект можно было бы разработать намного дешевле при таком подходе. Уверен, что и скорость выхода на окупаемость при таком подходе выше.
То, что все достаточно просто и занудно — да, но именно правильная простая работа часто ключ к успеху, а не «секрет» какой-нибудь.
Естественно, не гарантирую, т.к. бесплатных гарантий не бывает. Схема позволяет снизить риски и стоимость разработки, получив отклик от пользователей как можно раньше.
Еще многие российские магазины работают не на прямую с банками, а через платежные системы (рбкмоней и др.), так что на практике у мелкого магазина просто нет информации о кредитке, а крупный сервис сам заботится о безопасности. Воруют, мне кажется, при использовании физических банкоматов и накладок к ним или при вводе данных на всяких сомнительных сервисах.
SLA — это соглашение об уровне сервиса, NDA — соглашение о неразглашении. Написал SLA, а не NDA, чтобы подчеркнуть необходимость некоторого публичного предложения по дефолту, а то сам текст NDA часто чуть ли не секретней, чем данные, которые он охраняет.
Ладно, понял, что народ в свое массе на Хабре еще не созрел для таких вещей. Но особенность заключается в том, что большинство людей, кому это покажется важным, не будет писать в поддержку, а просто посчитает, что сервис не того уровня развития и уйдет. Какая-то часть клиентов потеряется просто из-за отсутствия политики по тому, что означает гарантия для обычного подписчика сервиса.
На этом постараюсь больше не писать на эту тему здесь. Сервису — успехов!
Материальная ответственность определяется инвидуально с клиентом.
Странно, у вас же массовый сервис. Что получает обычный клиент, который дополнительно не обговаривал этот вопрос (у вас же таких, как я понимаю, сейчас подавляющее большинство)?
тут и не принято по имени обращаться (даже и не обращал как-то раньше, что имя не заполнено)
Еще раз: гарантия без гарантийных обязательств — это обещание, а не гарантия. И то что усилия прикладываете, это так же обещания. Оценить качество ваших усилий со стороны практически не возможно, поэтому и существует понятие «гарантии» и серьезность ваших усилий подкрепляется серьезностью «гарантийных обязательств».
Весь вопрос в том, какие обязательства на себя берете. Из комментария видно:
— взлом вы не считаете вашей виной, компенсаций не будет никаких. Что вы считаете возможным признать вашей виной?
— гарантийные обязательства состоят из материальной ответственности. Какой размер убытков вы ей покрываете? Полный или на сколько ограниченный?
Немного по отдельным фразам:
— «Наши сотрудники материально заинтересованы в безопасности наших клиентов» — непонятно. Сотрудники редко реально заинтересованы в благополучии фирмы (если они не акционеры). Например, если сотруднику предложат подкуп 100тр за информацию по 1 конкретной фирме? Или 10млн руб за всю базу? Так ли вы уверены в мат. заинтересованности каждого сотрудника в этом случае?
— «безопасность аккаунтов подкреплена SSL протоколом» — SSL-протокол — это только от «подслушивания» общения между браузером и сервером, ничего о безопасности самого сервера и приложения это не говорит.
Конкретные вопросы остались, задал их выше. Они не столько по формулировке, сколько по сути вашей гарантии, поэтому юрист не к чему. Внезапно переходить от публичного общения в частное, по сути не получив ответов, не вижу смысла.
Ваши подходы так же важны, но они более дорогие и дополнительно покрывают более тонкие моменты, т.е. можно просто позже применять. Тут же важно добиться приемлемости результата первого релиза, т.е. чтобы им пользовались и за него платили деньги (по сути проверка идеи стартапа на прототипе). А потом уж, как у любого успешного сервиса, бесконечные доработки для увеличения пользовательской базы и прибыли.
Сам сайт очень многому еще не соответствует, активно переделываем.
Динамический серверный прототип (не просто хтмл/css/js) — отрицательно, если это не обкатка какой-нибудь новой для команды программистов технологии (отдельный вопрос, здесь не касаемся).
Все примерно как у вас, только программисты подключаются после дизайна и юзабилити тестирования. До этого верстальщики максимум. Почему так? Большинство стартапов не являются технически сложными, сомнений что это можно реализовать нет. Вопрос именно в пользователе: будет пользоваться или нет, будет платить за сервис (так или иначе) или нет. Дополнительно, программисты дороже, поэтому желательно, чтобы у них было меньше часов и меньше переделок.
С другой стороны, если вы, например, делаете систему распознания голоса, то дизайн после (если не нужно привлекать инвестиции), сначала должно нормально заработать распознание.
Если серьезно, то, цитата из разговора в «аське» об этой статье:
Я с ней согласен: just do it, пошагово. В своей практике, к сожалению, этого не наблюдаю (что люди кроме того что знают еще и делают, а новички еще и не знают).
И да, книги «Getting Real», «Rework» и «Дизайн пользовательского интерфейса II. Искусство мыть слона» рекомендую.
Схема же выработана на основе предыдущего личного опыта. Практически во всех прошлых проектах она бы принесла ощутимые результаты.
То, что все достаточно просто и занудно — да, но именно правильная простая работа часто ключ к успеху, а не «секрет» какой-нибудь.
Ладно, понял, что народ в свое массе на Хабре еще не созрел для таких вещей. Но особенность заключается в том, что большинство людей, кому это покажется важным, не будет писать в поддержку, а просто посчитает, что сервис не того уровня развития и уйдет. Какая-то часть клиентов потеряется просто из-за отсутствия политики по тому, что означает гарантия для обычного подписчика сервиса.
На этом постараюсь больше не писать на эту тему здесь. Сервису — успехов!
Странно, у вас же массовый сервис. Что получает обычный клиент, который дополнительно не обговаривал этот вопрос (у вас же таких, как я понимаю, сейчас подавляющее большинство)?
Еще раз: гарантия без гарантийных обязательств — это обещание, а не гарантия. И то что усилия прикладываете, это так же обещания. Оценить качество ваших усилий со стороны практически не возможно, поэтому и существует понятие «гарантии» и серьезность ваших усилий подкрепляется серьезностью «гарантийных обязательств».
Весь вопрос в том, какие обязательства на себя берете. Из комментария видно:
— взлом вы не считаете вашей виной, компенсаций не будет никаких. Что вы считаете возможным признать вашей виной?
— гарантийные обязательства состоят из материальной ответственности. Какой размер убытков вы ей покрываете? Полный или на сколько ограниченный?
Немного по отдельным фразам:
— «Наши сотрудники материально заинтересованы в безопасности наших клиентов» — непонятно. Сотрудники редко реально заинтересованы в благополучии фирмы (если они не акционеры). Например, если сотруднику предложат подкуп 100тр за информацию по 1 конкретной фирме? Или 10млн руб за всю базу? Так ли вы уверены в мат. заинтересованности каждого сотрудника в этом случае?
— «безопасность аккаунтов подкреплена SSL протоколом» — SSL-протокол — это только от «подслушивания» общения между браузером и сервером, ничего о безопасности самого сервера и приложения это не говорит.
Конкретные вопросы остались, задал их выше. Они не столько по формулировке, сколько по сути вашей гарантии, поэтому юрист не к чему. Внезапно переходить от публичного общения в частное, по сути не получив ответов, не вижу смысла.