Что-то в последнее время я слишком увлекся чтением. Голова уже отказывается воспринимать что-то новое. Надо остановиться и подумать.
В прошлые выходные скачал выступление Джейсона Фрида — основателя компании 37signals. Видео. Сегодня его просмотрел — это было поучительно (заметку о нем опубликую позже). Потом залез на Википедию (и ее английскую версию) и почитал, что там написано об этой организации. И какие ссылки даются в статье.
Одна из ссылок привела на книгу с описанием философии Getting Real. Выписки из нее ниже.
Полная версия здесь.
В книге все описано на примере разработки программного обеспечения для интернета, но при некотором приложении мозгов можно спроецировать знания и на другие области жизни.
Getting Real — это отказ от вещей, представляющих реальность (диаграммы, графики, схемы, стрелочки и модели) и создание реальной веши.
Getting Real значит оставаться небольшим и шустрым.
Getting Real — это создание того, в чём нуждается клиент и исключение того, что ему не нужно.
Getting Real дает лучшие результаты из-за того, что заставляет вас решать именно существующие проблемы, а не фантазировать на тему этих проблем.
Getting Real избавляется от…
* Временных диаграмм, простирающихся на месяцы или даже годы,
* Вымышленных функциональных спецификаций,
* Споров о масштабируемости
* Бесконечных собраний
* «Потребностей» нанимать десятки сотрудников
* Бессмысленных номеров версий
* Непорочных планов развития, предопределяющих идеальное будушее
* Бесконечных возможностей по настройкам
* Аутсорсинга поддержки
* Несоответствующего реальности тестирования
* Бесполезного бумагомарания
* Иерархии «сверху-вниз».
Месяцы планирования не так нужны. Месяцы написания спецификаций не так важны — спецификации должны иметь детали, выясненные в течении всей фазы развития. Не пробуйте закрыть все открытые проблемы и сохранить каждую деталь до начала разработки.
Сделайте меньше возможностей, но пусть они будут качественными. Вы не нуждаетесь в большом взрыве с новым релизом и кучей возможностей. Дайте пользователю немного, чтобы он мог понять и привыкнуть.
Если есть незначительные ошибки, завершите основную цель, а потом постепенно исправляйте ошибки. Тем самым вы ускорите ответную реакцию клиентов. Идеи могут великолепно выглядеть на бумаге, но на практике оказываются не такими уж и оптимальными. Чем скорее вы осознаете фундаментальные проблемы вашей идеи, тем лучше.
Как только вы начнёте всё делать быстро и реагировать на обратную связь с клиентом, вы установите прочную связь с клиентом. Помните, что цель состоит именно в том, чтобы получить постоянного клиента, создавая то, что они хотят.
Меньше соревнуйтесь
Народная мудрость гласит: чтобы подавить своих конкурентов, вы должны переиграть их. Это — тупик. Дорогой и параноидальный путь создания продуктов.
Так что же делать тогда? Ответ: меньше. Сделайте меньше чем ваши конкуренты, чтобы ударить по ним. Решайте простые проблемы и оставьте сложные, противные проблемы всем остальным. Вместо превосходства попробуйте делать недостаточно.
Мы будем раскрывать понятие «меньше» в этой книге, но для начинающих это:
* Меньше возможностей
* Меньше опций и настроек
* Меньше структура компании
* Меньше встреч и абстракций
* Меньше обещаний
Целью многих стартапов является привлечение денежных средств инвесторов. Но помните, если вы принимаете помощь инвесторов, вы несёте ответственность перед ними. Ожидания от стартапа вырастут. Инвесторы довольно быстро потребуют свои деньги обратно. Они (деньги) будут превыше качества разрабатываемого продукта.
Сейчас, чтобы начать, не требуется многого. Аппаратные средства дешевы и большое количество ПО бесплатно и имеет открытые исходные коды. И страсть не приходит с ценником.
Так что сделайте всё, что вы можете с теми деньгами, что уже у вас есть. Усиленно думайте и расставьте приоритеты. Ограничения заставляют думать творчески.
Лёгкий способ начать вовремя и уложиться в бюджет: фиксируйте время и бюджет. Никогда не отдавайте больше времени или денег проблеме, умерьте пыл.
Если вы не укладываетесь в отведённые время и бюджет, не увеличивайте их. Вместо этого сократите возможности. Время добавить их чуть позже будет всегда.
Выясните, что действительно важно. Что сподвигло на создание продукта? Это вызовет ограничения, которые сподвигнут вас на принятие быстрого, точного и жёсткого решения вместо тупого «мямления».
Иногда лучший способ узнать, каким должно быть ваше приложение — это узнать, каким оно не должно быть. Пусть это будет врагом вашего приложения, и вы будете видеть свет, на который вы должны идти.
Бонус, который вы получаете при наличии врага — весьма ясное маркетинговое сообщение. Людей топит конфликт. И они также сравнивают продукт с другими продуктами. Выбирая врага, вы даёте людям то, что они хотят увидеть. И они не только будут понимать ваш продукт лучше и быстрее, они встанут на вашу сторону. Это безошибочный способ получить внимание и зажечь страсть.
Специалисты по маркетингу (и все люди) хорошо «обучаются» следовать за лидером. Естественный иснтинкт должен выяснить, что работает для борьбы, а затем пробуйти превзойти это — чтобы быть дешевле своего конкурента, который конкурирует ценой, или быстрее, если он конкурирует скоростью. Проблема в том, что как только потребитель купил чью-либо неверную историю и верит этой лжи, убеждать его переключиться — то же самое, что убеждение его в том, что он был неправ. А люди очень не любят признавать свою неправоту.
Вместо это расскажите другую историю и убедите его, что эта ваша история важнее, чем история, которой он сейчас верит. Если ваше соревнование в том, кто быстрее — вы должны стать более дешёвым. Если кто-то продаёт историю здоровья, вы должны продать историю удобства. Не только говоря «мы более дешёвые», но и предоставляя реальную историю, отличающуюся от существующих.
Чем меньше в вашем приложении рутины — тем лучше.
Чем вы беднее, тем проще это изменить.
Чем больше объект, тем больше нужно энергии для его изменения. Это так же верно в деловом мире, как и в обычном.
Размеры увеличивают:
* долгосрочные контракты
* большой штат сотрудников
* неизменные решения
* cовещания о других совещаниях
* долгий процесс
* обширный инвентарь (физический или умственный)
* привязка к оборудованию или программам
* закрытые форматы данных
* управление будущим на основе прошлого
* долгосрочные цели
* офисная политика
Уменьшить размеры позволяют:
* решения, принимаемые по мере надобности
* многозадачность членов команды
* установка ограничений вместо попыток их преодолеть
* уменьшение программного обеспечения, меньше кода
* меньшее количество функций продукта
* маленькая команда
* простота
* открытые исходные коды
* открытые форматы данных
* свободная атмосфера, в которой легче признавать ошибки
Меньшие размеры позволят вам быстрее изменить направление. Вы можете реагировать и развиваться. Вы можете сфокусироваться на хороших идеях и выкинуть плохие. Вы можете слушать своих клиентов и отвечать им. Вы можете внедрить новые технологии сейчас, а не потом. Вместо авианосца вы управляете моторной лодкой. Получайте удовольствие от этого обстоятельства.
Перемены — ваш лучший друг. Чем выше их цена, тем меньше их вероятность. И если ваши конкуренты могут меняться быстрее вас, вы в крайне невыгодном положении. Если цена перемен становится слишком высока — вам конец.
Вот где бедность действительно поможет вам. Копеечная стоимость перемен — это то, что есть у маленьких команд по умолчанию, у больших команд этого не будет никогда. Вот тут большие ребята действительно завидуют маленьким ребятам. В большой организации на какое-то изменения потребуется неделя, а в малой — это займет всего один день. Это преимущество бесценно. Дешевые и быстрые перемены — секретное оружие малого бизнеса.
Простые правила, как с моделированием птиц, приводят к сложному поведению. Сложные правила, как, например, налоговое законодательство большинства стран, провоцируют глупое поведение.
Чем больше жестких установок мы применяем, тем меньше места для творческих и необычных решений.
Удерживайте команду насколько возможно маленькой. Закон Меткалфа, который гласит «полезность сети приблизительно равна квадрату численности пользователей этой сети», применительно к участникам команды обретает иной смысл: эффективность команды обратно пропорциональна квадрату количества ее участников.
Пусть ограничения ведут вас к творческим решениям.
Вместо рассуждений об этих ограничениях, примите их. Пусть они ведут вас. Ограничения управляют новизной и центром силы. Вместо попытки сместить их, используйте как преимущество.
Ограничения — часто замаскированы. Забудьте о вкладе капиталов с риском, длинном цикле релизов, и быстром найме людей. Вместо этого, работайте с тем, что у вас есть.
Дифференцируйте себя от больших компаний, будьте дружественнее и доступнее
Маленькие компании наслаждаются меньшими формальностями, меньшей бюрократией, и большей свободой. Маленькие компании ближе к клиенту по умолчанию. Это означает, что они могут связаться прямо и лично с клиентами. Ваш сайт и ваш продукт могут иметь человеческие тексты, вместо зондирования корпоративных трутней. Ваши клиенты будут говорить непосредственно с вами, а не с продавцами, которые тянут вниз компанию.
Перед тем как вы начнете проектировать или кодировать что-либо, вам нужно знать цель вашего продукта — видение. Думайте. Почему это может существовать? В чем будут отличия от других подобных программ?
Успех и удовлетворение находится в деталях.
Однако, успех не единственная вещь, которую вы найдете в деталях. Вы также найдете — застой, разногласие, встречи, и задержки. Эти вещи могут убить моральное состояние и снизить вероятность успеха.
Как часто вы сидите над одной строчкой кода в течение целого дня? Как часто ваша работа сделанная за один день не дала никакого прогресса? Это случается, когда вы сосредоточиваетесь на деталях, слишком рано. У взыскательного человека будет еще много времени на детали. Просто отложите это.
Не волнуйтесь о размере шрифта в заголовках. Вы не нужна совершенная тень. Вам не нужно перемещать кнопку на три пикселя вправо или влево. Просто поместите материал на страницу. А затем используйте. Убедитесь, что это работает. Позже вы можете все усовершенствовать.
Детали проявляются, пока вы используете то, что вы строите. Вы будете видеть, чему нужно уделить больше внимания. Вы будете знать, какие выбоины надо замостить, потому что вы будете продолжать биться об них. Именно тогда, на них следует обратить внимание, не раньше.
Дьявол в деталях
Если вы начинаете втягиваться в детали немедленно, можете быть уверены что рисунок будет плохим. Фактически, вы целиком не понимаете суть дела.
Не тратьте бесцельно время на проблемы, которых у вас еще нет
Не работайте над материалом, пока вы фактически не должны этого делать.
Найдите основной рынок для вашего приложения и сосредоточьтесь исключительно на нем
Если вы ориентируетесь на всех, вы не удовлетворите никого
Создайте половину продукта, но законченный продукт
Начните быстро создавать приложение и позвольте ему приобретать инерцию. Затем вы можете начать добавлять функции и возможности твердой основе, которую вы построили.
Наш любимый ответ на вопрос «Почему вы не сделали это или почему вы не сделали то?». Всегда такой: «Поскольку это не имеет значения».
Хорошо если были бы эти функции? Безусловно. Но являются они сутью? Будут ли они востребованы? Нет. И вот почему мы их опустили. Лучшие проектировщики и лучшие программисты — не те, у кого лучшие навыки, или самые проворные пальцы, или не те, кто может сделать красивый макет в Photoshop, — это те, кто может определить, что имеет значение. Это те, кто понимает реальные выгоды от решения.
Сделайте добавление новых функций трудно осуществимой задачей
Практичный совет: Создавайте конструкции и услуги, которыми вы можете управлять. Легко давать обещания. Намного сложнее сдержать их. Сделайте то, что вы можете подтвердить фактически, организационно, стратегически, и материально.
Спросите людей, чего они не хотят
Больше «не» в вопросах. Иногда лучшее, что вы можете сделать для клиентов — опустить какую-нибудь функцию.
Новшества приходят из сказанного «нет»
Нет никакой необходимости отправлять веб-программы в плавание совершенными. Проектируйте интерфейсы, используйте их, анализируйте, а затем начинайте снова.
Вот процесс Get Real, который мы используем:
Мозговой штурм
Быстрые, простые эскизы — это самый экономичный способ начать проектирование. Выводите свои идеи на бумагу, пусть и небрежным почерком.
Делайте html версии того, что изображено на эскизах.
Когда макет демонстрирует достаточное количество необходимой функциональности, можно приступать к программированию.
Настройки — зло, потому что они раздувают программное обеспечение и требуют больше кода. А в реальности очень часто настройками никто даже не пользуется
Сокращайте время разработки, разбивая месяцы на недели. Если проект требует 12 недель работы, разбейте его на 12 небольших кусков. Если проект требует 30 часов работы, разбейте на куски по 6-10 часов и делайте каждый шаг за один раз, за один день.
Вы сталкиваетесь с большой проблемой, которую уже не в состоянии держать в голове. Разделите ее на кусочки, каждый из которых сможете обдумать с легкостью и решить за один шаг.
У многих компаний такие направления как проектирование, развитие, копирайтинг, поддержка, маркетинг разделены на отделы. Такая специализация по отделам, конечно, имеет свои преимущества, но также создает ситуацию, когда сотрудники видят только свой маленький мир, а не полный контекст веб-приложения.
Как можно больше смешивайте команду по различным специализациям, так чтобы наладить диалог между всеми в процессе работы. Не позволяйте чему-то теряться из-за отсутствия диалога в команде. Пусть копирайтеры работают над текстом вместе с проектировщиками. Убедитесь, что разработчики видят, как работает поддержка.
Еще лучше нанять людей с разными талантами, которые они будут применять в течение всей работы над проектом. Результатом будет более гармоничный продукт.
Известно, что многие люди предпочитают работать рано утром или поздно вечером — это время когда их не беспокоят, это время самое продуктивное для них. Это время становится таким, потому что никто не прерывает работу, и никто не отвлекает.
Поэтому можно установить правило: сделать половину рабочего дня единым временем для работы. В это время не отвлекаться на телефонные звонки, чтение почты, ненужное общение с коллегами и т.д.
Избегайте любых перерывов во время единого времени работы. Каждый перерыв снижает производительность и отвлекает настолько, что потом опять необходимо вникать в работу. Это все снижает продуктивность и увеличивает количество часов, требуемых для выполнения работы.
Нет страшнее яда для производительности, чем встреча. У этого несколько причин:
1. Встречи разбивают рабочий день на отдельные куски и этим прерывают ваш естественный технологический процесс.
2. Встречи — это всего лишь слова и абстрактные понятия.
3. Встречи несут безнадежно мало полезной информации в минуту.
4. На встречах часто присутствует один слабоумный, который неизбежно заставляет всех тратить на него общее время.
5. У встреч есть повестки дня, такие неопределенные, что часто никто действительно не уверен в том, что надо обсуждать.
6. Встречи требуют большой подготовки, чего почти никто не делает.
Если все-таки вы не можете избежать встречи (что должно быть очень редким событием), воспользуйтесь простыми правилами:
1. Встреча должна быть не более 30 минут. Установите таймер, после 30 минут прерывайте встречу.
2. Пригласите как можно меньше участников.
3. Никогда не участвуйте во встрече без ясной повестки дня.
Самое главное в разработке программного обеспечения — мотивация. Сначала мотивация, потом возможности. Только с мотивацией можно сделать что-то действительно хорошо.
Долгие, затянутые циклы разработки — убийцы мотивации. Это слишком долгое время между празднованием побед. Быстрые победы — факторы мотивации. Если вы допускаете длинные циклы разработки — вы убиваете мотивацию. И это может убить ваш продукт.
Среди многих месяцев разработки посвятите один день в неделю для маленькой победы. Спросите себя: «Что можно сделать и выпустить за 4 часа?». Затем сделайте это.
Даже если у вас есть доступ к сотне лучших людей, это все равно плохая идея попробовать нанять их всех одновременно. Нет никакого способа, с помощью которого вы смогли бы сразу объединить столь много людей в гармоничный коллектив. Вы неизбежно столкнетесь с головной болью обучения, межличностными конфликтами, непониманием в общении, людьми с разными направлениями мышления и многим другим.
Так что не нанимайте. Серъезно, не нанимайте никого. Взгляните на это с другой стороны — действительно ли работа, которая вас отягощает, так необходима? Что случиться, если вы просто её не сделаете? Можете ли вы решить проблему с данной частью системы другим способом?
Не переживайте если какие-либо внештатные увлечения отвлекают ваших сотрудников от их основной работы. Перефразируя избитое выражение: если хочешь, чтобы дело было сделано хорошо, доверь его самому занятому человеку.
Быстро обучающиеся универсалы лучше закостенелых авторитетов
В маленьких командах нужны мастера «на все руки». Каждому нужно мыслить системно. Каждый должен уметь общаться с клиентами. И, в случае необходимости, каждый должен уметь, резко «дав по тормозам», развернуться контролируемым заносом. Запомните, маленьким командам иногда надо изменить направление и сделать это быстро. Вам нужен тот, кто сможет учиться, привыкать, приспосабливаться, а не закостенелый брюзга, специализирующийся на чём-то одном.
Берите счастливых середнячков, а не разочаровывающих гуру. Берите того, у кого есть энтузиазм.
Обратите внимание, задает ли соискатель вопросы о вашем проекте. Увлеченные программисты хотят максимально разобраться в проблеме и готовы сразу предложить потенциальные решения или улучшения, — и поэтому много спрашивают.
Если вы задумываетесь над тем, какого рода специалиста можно еще пригласить на не занятое место, — наймите того, кто лучше других умеет вести документацию. Не важно кто он — дизайнер, программист, специалист по продажам или кто-то еще, его умение хорошо писать окупится с лихвой. Хороший писатель не просто тот, кто грамотен. Хорошие писатели знают как донести суть. Они делают сложное — понятным. Они умеют посмотреть на вещи «непонимающим» взглядом.
Сначала — интерфейс
Создавайте дизайн интерфейса до того как начнете программировать.
Слишком много приложений создаются с подходом «сначала программируем». Это неудачная идея. Программирование — самое сложное в создании приложения, а это значит, что и самая дорогая. И создав код, вам будет сложно его изменить. Вместо этого начинайте с дизайна интерфейса.
Другая причина для того, чтобы начинать с дизайна в том, что интерфейс и есть продукт. Вы продаете людям то, что они видят. И если вы оставите интерфейс «на потом», огрехи будут заметны.
Начинайте с самого важного на странице и двигайтесь вширь
Дизайн от эпицентра фокусирует внимание на том, что наиболее важно на странице, а затем обращается к менее важному. Это значит, что сначала вы игнорируете то что находится кругом — навигацию, закладки, «подвал» страницы, цвета, логотип и так далее. Вместо этого, вы начинаете с эпицентра и сначала разрабатываете наиболее важную часть страницы
Делайте дизайн для обычного, пустого, и ошибочного состояния страницы.
Для каждого экрана вы должны рассмотреть три состояния:
* Обычное. Экран, который люди видят каждый день при работе с приложением, заполненным данными.
* Пустое. Экран, который люди видят при первом запуске, и ещё не успели ввести данные.
* Ошибка! Экран, который люди видят, когда что-то идёт не так.
Тише едешь – дальше будешь. Появилась идея – подождите неделю, прежде чем ее воплощать, посмотрите, будет ли она казаться такой же хорошей, когда шум спадет. Помаринуйте идею – и, может быть, за это время вам в голову придет еще более простое решение.
Научите программистов отстаивать свою точку зрения на то, как лучше написать программу.
Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше.
Стройте, а не пишите. Если вам нужно что-то объяснить, попробуйте это изобразить и сделать в качестве прототипа, вместо того чтобы долго документировать. Реальный интерфейс или прототип уже находятся на пути воплощения в реальный продукт. А лист бумаги, напротив, – лишь на пути в мусорную корзину.
Мир полон шума и суеты. Чтобы вас заметили среди всего этого, раздавайте что-нибудь бесплатно.
Сделайте регистрацию и отказ безболезненными
Сделайте форму для регистрации как можно короче. Не запрашивайте информацию, которая вам не нужна, и не заваливайте пользователей длинными анкетами.
Также создайте условия, чтобы люди могут получить свои данные, если они решат уйти. Мы обеспечиваем пользователям возможность легко экспортировать их сообщения и комментарии в формате xml в любое время. Это их данные, поэтому они могут делать с ними что хотят.
Это критический фактор, потому что давая людям власть над их информацией, вы создаете доверие. Вы обеспечиваете им мост к их островкам данных. Вы позволяете им уйти без потерь, если они найдут лучшее предложение. Это – правильно, и это строит добрую волю.
Избегайте долгосрочных контрактов, платы за подключение и т.д.
Не придумывайте всякие «фокусы» чтобы получить побольше денег. Зарабатывайте их.
Вам приходится объявлять плохие новости, такие как увеличение цены? Сделайте это как можно более безболезненным, сообщив об этом заранее. Также подумайте о том, чтобы освободить существующих пользователей от повышения цены на какое-то время. Эти люди обеспечивают вам хлеб с маслом, и вы хотите, чтобы они чувствовали себя уважаемыми, а не жертвами вымогательства.
Чтобы спровоцировать разговоры и ожидание, выпускайте программу в стиле Голливуда: 1) Анонс (teaser, буквально: дразнилка – прим. перев.), 2)Рекламный показ отрывков, 3) Выпуск.
Реклама стоит дорого. А оценка эффективности различных типов рекламы может оказаться дороже самой рекламы. Когда у вас нет времени или денег, чтобы пойти по традиционному рекламному пути, подумайте о другом пути: рекламируйте через блоги.
Начните с создания блога, который не только хвалит ваш продукт, но еще и предлагает полезные советы, решения, ссылки и т.д. На наш блог Signal vs. Noise приходят тысячи читателей в неделю, благодаря полезным, информативным и интересным фрагментам и историям, которые мы помещаем ежедневно.
Как технология продвижения, обучение – мягкий путь к тому, чтобы ваше имя – равно как и название вашего продукта – появилось перед множеством людей. И вместо того, чтобы заниматься навязыванием продукта, вы получаете внимание за предоставление ценной услуги. Это создает позитивный настрой, недостижимый для традиционного маркетинга. Те, кого вы научите, потом станут вашими проповедниками.
Вам полезно знать, кто о вас говорит. Проверьте свои логи и узнайте, что откуда берется. Кто на вас ссылается? Кто ругается? Какие из блогов, попавшие в списки на Technorati, Blogdex, Feedster, Del.icio.us и Daypop, говорят о вас?
Узнайте это, а затем дайте другим почувствовать ваше присутствие. Оставьте комментарии в этих блогах. Поблагодарите людей за ссылки. Спросите, хотят ли они, чтобы их включили в списки рассылки о предстоящих выпусках, обновлениях и т.д. Соберите положительные отзывы и создайте страницу дискуссий и благодарностей на вашем сайте. Похвалы пользователей – замечательный способ продвижения вашей программы, потому что отзывы третьих лиц вызывают большее доверие у большинства людей.
Если отзывы отрицательные, все равно отнеситесь к ним внимательно. Покажите, что вы к ним прислушиваетесь. На критику отвечайте обдуманно. Что-то типа: “Мы ценим ваши отзывы, но мы сделали это таким-то способом, потому что…” Или: “Вы затронули важную проблему, и мы над ней работаем”. Вы смягчите критику и покажете человеческое лицо вашего продукта. Удивительно, насколько обдуманный комментарий в блоге может рассеять напраслину и даже превратить жалобщиков в сторонников.
Сокрушите стены между разработкой и поддержкой
В ресторанном бизнесе есть большая разница между теми, кто работает на кухне, и теми, кто работает непосредственно с клиентами. Важно, чтобы каждая сторона понимала другую и знала ее интересы. Вот почему во многих кулинарных школах и ресторанах повара часто заменяют официантов, чтобы работники кухни взаимодействовали с клиентами и видели, что в действительности происходит на переднем крае.
Используйте встроенную систему помощи и списки часто встречающихся вопросов, чтобы ваш продукт не требовал справочников или тренингов
Пользователям нравится прямота, и часто их недовольство на глазах превращаются в вежливость, когда вы отвечаете быстро и прямо.
Будьте готовы сказать “нет” своим пользователям
Используйте форум или чат, чтобы пользователи имели возможность помогать друг другу
Публикуйте ваши неудачи
Выпустите плохие новости и уберите их с дороги
Если что-либо пошло не так, расскажите людям. Даже если они не заметили.
Заметим еще по поводу новостей, плохих и хороших. Когда появляются плохие новости, выпустите их сразу. Хорошие новости, с другой стороны, выпускайте медленно. Если вы можете продлить прекрасные чувства, сделайте это.
Будьте оперативны, прямы и честны
Выпустите обновление через 30 дней после выпуска
Быстрое обновление показывает движение. Показывает, что вы прислушиваетесь к советам пользователей. Показывает, что у вас еще есть «порох в пороховницах». Оно дает вторую волну разговорам. Оно подкрепляет первоначальные положительные эмоции, связанные с вашим продуктом. Оно дает пищу для обсуждения и сообщений в блогах.
Не нужно сразу же исправлять каждую ошибку. Большинство ошибок надоедливы, но не смертельны. Те, которые надоедливы, могут быть отложены. Ошибки типа “что-то тут выглядит не так” и подобные можно без ущерба отложить на некоторое время. А уж если ошибка ломает вашу базу данных – тогда, конечно, она должна быть исправлена немедленно.
Если раскачивать лодку, появляются волны. Когда вы добавляете новую функцию, изменяете правила или удаляете что-нибудь – реакции будут разными, и часто отрицательными.
Избегайте паники и желания быстро все поменять в ответ. Да, вначале страсти кипят. Но если вы переждете этот начальный период, который составляет 24-48 часов, все уляжется. Большинство пользователей реагируют на изменения до того, как они действительно изучили и использовали то, что вы добавили (или смирились с тем, что вы удалили). Так что расслабьтесь, и не двигайтесь, пока не пройдет некоторое время. И тогда уж вы сможете предложить более продуманный ответ.
С развитием событий не бойтесь противостоять разбуханию. Всегда будет соблазн расширять продукт в объеме. Но это делать не обязательно. То, что продукт растет и становится более зрелым – не должно значить, что и более сложным.