На днях дочитал книгу «Getting Real» от 37signals (известные люди в определенной среде). Читал на русском языке прямо на сайте, бесплатно. Книга оказалась очень познавательной, полезной и интересной. Перевод очень хороший (если не считать несколько ошибок и пару разрушающих мозг фраз).
Getting Real — это своеобразный подход к разработке, запуску и сопровождению веб-приложений. По своей сути близок к методологии Agile. Основные тезисы: минимальные вложения, минимальный функционал (ничего лишнего) максимальное качество, тесное и открытое взаимодействие с пользователем (клиентом).
Подробнее о подходе и принципах Getting Real написано в главе 1 «Введение».
Вся книга представляет собой набор советов о том, как правильно делать всё в процессе разработки и выпуска веб-приложения. Покрываются практически все вопросы: от технических, до управленческих и маркетинговых.
Но авторы несколько раз обращают внимание на то, что Getting Real легко проецируется на другие области работы и жизни:
«Хоть внимание и акцентируется на разработке веб-приложений, идеи применимы к действиям вне этой сферы. Предложения маленьких групп, быстром создании макетов, ожидание итераций и многие другие могут служить руководством, запускаете ли вы бизнес, пишете ли книгу, проектируете ли веб-сайт, записываете ли альбом или делаете что-то другое. Как только вы начнёте следовать принципам Getting Real в одной области жизни, вы поймёте, как это можно использовать в других областях».
Стиль написания свободный. Настроения авторов революционные.
«Потерпите нас. Мы считаем — лучше представить идеи резко, чем тихо шептать об этом на ухо. Если это кажется дерзким и высокомерным, пусть так и будет. Мы предпочитаем быть «провокаторами», чем постоянно ныть «может быть, если…». Конечно, будут времена, когда эти правила должны будут измениться или исчезнуть. И некоторые из этих тактик, возможно, не подходят к вашей ситуации. У вас есть своя голова на плечах, решайте сами».
Авторы обращают внимание на реальные проблемы, с которыми разработчики и менеджеры сталкиваются изо дня в день, но при этом порой их даже не замечают (не принимают за проблемы), или пытаются закрыть на них глаза. В то же время книга призывает откинуть ряд надуманных проблем, которые возникают из-за чрезмерной бюрократизации процессов разработки, попыток сделать всё и сразу, неправильного подхода к планам и срокам. Этих проблем может вовсе не стать, если применять подход Getting Real.
В книге повсеместно присутствуют вставки из других книг, блогов и статей известных авторов. Это добавляет уверенности в том, что время читателя не тратится впустую, и показывает, как описанные подходы применяются в разных компаниях.
Далее просто перечислю ключевые идеи по главам с цитатами из книги. С одной стороны, это — краткий пересказ, и если вы надумали прочитать книгу, то лучше сначала прочтите ее, а потом вернитесь к моей выжимке для закрепления. Если читать книгу не решились, то стоит хотябы прочитать выдержки.
Глава 2. «Начало»
«Сделайте меньше чем ваши конкуренты, чтобы ударить по ним. Решайте простые проблемы и оставьте сложные, противные проблемы всем остальным. Вместо превосходства попробуйте делать недостаточно».
Пишите программы для себя.
«Если вы решаете собственную проблему, вы создаёте инструмент с душой. И это является ключевым. Это означает, что вы сделаете всё отлично. И это является лучшим вариантом».
Финансируйте себя сами.
«Сейчас, чтобы начать, не требуется многого. Аппаратные средства дешевы и большое количество ПО бесплатно и имеет открытые исходные коды. И страсть не приходит с ценником».
Фиксируйте время и бюджет.
«Бытует миф: мы можем начать вовремя, уложившись в бюджет и реализуя всё предполагаемое. Это практически никогда не выходит, но когда так происходит, от этого страдает качество.
Если вы не укладываетесь в отведённые время и бюджет, не увеличивайте их. Вместо этого сократите возможности. Время добавить их чуть позже будет всегда.
В начале пусть лучше будет меньше запланированных возможностей, чем потом будет посредственный, громоздкий и с кучей дыр безопасности результат. Оставьте волшебство Копперфильду. У вас реальный бизнес и реальный продукт».
Заведите себе врага.
«Иногда лучший способ узнать, каким должно быть ваше приложение — это узнать, каким оно не должно быть. Пусть это будет врагом вашего приложения, и вы будете видеть свет, на который вы должны идти».
Меньше рутины.
«Чем меньше в вашем приложении рутины — тем лучше.
Если рутинной работы немного и она управляема — вы можете наслаждаться».
Глава 3. «Оставайтесь небольшими».
Меньше размеры.
«Ловкие, проворные и легковесные компании могут быстро менять свою бизнес-модель, продукт, его функции и маркетинг. Они могут делать ошибки и быстро их исправлять. Они могут менять приоритеты, и что самое важное — у них есть право передумать».
Снизьте стоимость перемен.
«Перемены — ваш лучший друг. Чем выше их цена, тем меньше их вероятность. И если ваши конкуренты могут меняться быстрее вас, вы в крайне невыгодном положении. Если цена перемен становится слишком высока — вам конец».
Начните с троих.
«Чтобы выпустить первую версию вашего продукта, можно начать только с тремя людьми. Это магическая число, которое обеспечит вам достаточный человеческий ресурс и в то же время позволит оставаться быстрым и проворным. Начните с разработчиком, дизайнером, и человеком, — который разбирается в том и другом».
Принимайте ограничения.
«Пусть ограничения ведут вас к творческим решениям».
Будьте собой.
«Много маленьких компаний делают ошибку в попытках действовать как большие. Как будто бы они не замечают свой размер. Это как слабость, комплекс, который нужно скрывать, и это слишком плохо. Быть маленьким фактически обладать огромным преимуществом, особенно, когда это касается коммуникации».
Глава 4. «Приоритеты».
В чем идея?
«Найдите свою большую идею и примите решение о видении, все маленькие решения в будущем станут проще и легче».
Пренебрегайте деталями в начале.
«Успех и удовлетворение находится в деталях.
Однако, успех не единственная вещь, которую вы найдете в деталях. Вы также найдете — застой, разногласие, встречи, и задержки. Эти вещи могут убить моральное состояние и снизить вероятность успеха».
Проблема тогда, когда это проблема.
«Вам действительно нужно волноваться о вычислениях для 100 000 потребителей сегодня, если это будет у вас через два года?
[…]
Принимайте решения вовремя, когда у вас есть доступ к реальной информации, которая необходима. Тем временем, вы сможете сосредоточить внимание на вещах, которые требуют непосредственной заботы».
Сосредоточтесь на своих клиентах.
«Клиент не всегда прав. Правда в том, что вам придется определять кто прав, а кто ошибается — в рамках вашего приложения. Хорошая новость в том, что интернет делает поиск правильных людей легче, чем когда-либо.
Если вы ориентируетесь на всех, вы не удовлетворите никого».
Расширяйтесь и оптимизируйтесь позже.
«В начале, сделайте основу продукта, вместо масштабируемости. Создайте большое приложение, а затем тревожьтесь о том, что делать, как только оно стало успешным. Иначе вы, возможно, расточаете энергию, время, и деньги, фокусируетесь на том, что может никогда не случиться».
Делайте идейное ПО.
«Лучшее программное обеспечение имеет свое виденье. Лучшее программное обеспечение лавирует между потребностями. Когда кто-нибудь использует программное обеспечение, они не только, ищут особенности, они ищут подход. Они ищут видение для решения своих задач. Решите, что такое — ваше виденье и идите с этим».
Глава 5. «Выбор функций».
Лучше хорошая половина, чем плохое целое.
«Остерегайтесь подхода в развитии сетевого приложения, в котором все готово, но вот что-то не работает и это что-то очень важное.
[…]
Начните быстро создавать приложение и позвольте ему приобретать инерцию. Затем вы можете начать добавлять функции и возможности твердой основе, которую вы построили».
Это не имеет значения.
«Наш любимый ответ на вопрос «Почему вы не сделали это или почему вы не сделали то?». Всегда такой: «Поскольку это не имеет значения».
Меньше функций.
«Сделайте добавление функций, трудно осуществимой задачей. Пусть каждая функция и особенность доказывает, что ее надо оставить в живых. Подобно «Бойцовскому клубу». Вы должны рассматривать только те функции и особенности, которые были протестированы в течение трех дней и за это время были востребованы максимально.
[…]
Для каждой новой функции от вас потребуется:
- 1. Сказать «нет».
- 2. Вынудить функцию доказать свое значение.
- 3. Если снова «нет», уже конец. Если, «да», продолжайте…»
Можете ли управлять этим?
«Создавайте конструкции и услуги, которыми вы можете управлять. Легко давать обещания. Намного сложнее сдержать их. Сделайте то, что вы можете подтвердить фактически, организационно, стратегически, и материально».
Решение задач пользователей.
«Не навязывайте людям решения. Вместо этого пусть каждый будет генералом над программным обеспечением и сможет найти собственное решение проблемы. Предоставьте людям то, с помощью чего достаточно просто разрешить их собственные проблемы и найти собственный путь».
Забудьте о запросах функций.
«А что вы делаете со всеми этими запросами, которые к вам поступают? Где вы их храните? Как вы управляете ими? Вы этого не делаете. Просто читаете их, а затем отбрасываете.
[…] Пусть ваши клиенты будут вашей памятью. Если это действительно стоящая функция, они будут напоминать вам, пока вы не сможете не забыть».
Глава 6. «Процесс».
Запустите программу быстрее.
«С запуском программы в реальную работу, вы добирается до истинного понимания того, как она должна работать. Вы избегаете бурных разговоров, эскизов и длинных текстов, которые отдаляют вас от сути. Вы осознаете, какие мысли были тривиальны, а какие критически неприемлемы».
Не всё с первого раза.
«Не ожидайте того, что будете все понимать и делать правильно с первого раза. Пусть приложение растет и общается с вами. Позвольте ему трансформироваться и эволюционировать».
От идеи до реализации.
«Перейдите от мозговых штурмов — к эскизам — к HTML — к кодированию».
Избегайте настроек.
«Настройки — зло, потому что они раздувают программное обеспечение и требуют больше кода. А в реальности очень часто настройками никто даже не пользуется. Настройки подразумевают, что вы мало знаете о том, как должны быть расположены блоки на странице, сколько сообщений должно быть выведено на страницу и т.п.
[…]
Вы сталкиваетесь с ограничением: сколько сообщений должно быть на странице? Ваша первая мысль сделать выбор 25, 50 или 100. Это легкий выход. Просто примите решение, как сделать лучше. И выберите одно число».
Сделано!
«Сделано! Это волшебное слово. Когда вы уже сделали — вы получили опыт и можете идти дальше.
Но подождите, а что если вы сделали что-то неправильно? Это плохо. Но это не нейрохирургия, это — сетевое приложение. Нет ничего страшного. Не нужно только замедлять процесс анализом ошибок. Вместо этого оцените важность и идите дальше».
Тестируйте в реальных условиях.
«Нет никакой замены реальных людей, использующих ваше приложение в действительности. Получите реальные данные. Получите реальную обратную связь. Затем улучшайте, основываясь на этой информации».
Глава 7. «Организация».
Не разделяйте лишний раз.
«У многих компаний такие направления как проектирование, развитие, копирайтинг, поддержка, маркетинг разделены на отделы. Такая специализация по отделам, конечно, имеет свои преимущества, но также создает ситуацию, когда сотрудники видят только свой маленький мир, а не полный контекст веб-приложения».
Единое время.
«Известно, что многие люди предпочитают работать рано утром или поздно вечером — это время когда их не беспокоят, это время самое продуктивное для них. Это время становится таким, потому что никто не прерывает работу, и никто не отвлекает.
Поэтому можно установить правило: сделать половину рабочего дня единым временем для работы. В это время не отвлекаться на телефонные звонки, чтение почты, ненужное общение с коллегами и т.д».
Встречи ядовиты.
«Вам действительно нужны встречи? Встречи обычно возникают, когда что-то не достаточно ясно. Вместо встречи, попытайтесь упростить обсуждение и воспользуйтесь мессенджером или Campfire. Минута встречи крадет минуту реальной работы. Поставьте себе цель — избегать встреч».
Маленькие победы.
«Долгие, затянутые циклы разработки — убийцы мотивации. Это слишком долгое время между празднованием побед. Быстрые победы — факторы мотивации. Если вы допускаете длинные циклы разработки — вы убиваете мотивацию. И это может убить ваш продукт».
Глава 8. «Персонал».
Нанимайте меньше, нанимайте позже.
«Так что не нанимайте. Серъезно, не нанимайте никого. Взгляните на это с другой стороны — действительно ли работа, которая вас отягощает, так необходима? Что случиться, если вы просто её не сделаете? Можете ли вы решить проблему с данной частью системы другим способом?»
Проверяйте.
«Прежде чем мы нанимаем кого-либо, мы даем ему на пробу небольшой проект. Мы смотрим, как он ведёт проект, как общается, как работает и т.д. Наблюдение за тем, как человек проектирует или кодирует несколько страниц, даст вам множество информации для понимания того, подходит он вам или нет».
Не по словам, а по делам.
«Проекты с открытым кодом — находка для того, кто ищет техперсонал. Они дают вам возможность следить длительное время за работой того или иного специалиста.
Это значит, вы можете оценивать людей по-сделанному, а не по-сказанному».
Нанимайте эрудитов.
«Мы никогда не наймем кого-либо, чья профессия называется «разработчик структуры системы программного обеспечения». Это уж слишком. В маленьких командах, таких как наша, нет смысла в подобного рода узких специалистах.
В маленьких командах нужны мастера «на все руки».
Неподдельный энтузиазм.
«Энтузиазм. Свойство, не передающееся даже самым умелым притворством. Пришло время нанять кого-то в команду? Не думайте, что нам нужен гуру или хорошо известный (в тесных кругах) специалист. Такие всё равно чаще всего выступают в роли «свадебных генералов». Счастливый специалист средней руки лучше раздражённого эксперта».
Нанимайте хороших писателей.
«Если вы задумываетесь над тем, какого рода специалиста можно еще пригласить на не занятое место, — наймите того, кто лучше других умеет вести документацию».
Глава 9. «Создание интерфейса».
Сначала — интерфейс.
«Слишком много приложений создаются с подходом «сначала программируем». Это неудачная идея. Программирование — самое сложное в создании приложения, а это значит, что и самая дорогая. И создав код, вам будет сложно его изменить. Вместо этого начинайте с дизайна интерфейса.
[…]
Другая причина для того, чтобы начинать с дизайна в том, что интерфейс и есть продукт. Вы продаете людям то, что они видят. И если вы оставите интерфейс «на потом», огрехи будут заметны».
Дизайн от эпицентра.
«Без чего страница аобсолютно не может быть — это без эпицентра. К примеру, если вы разрабатываете страницу, которая показывает пост в блоге, пост — это и есть эпицентр. Не категории в сайдбаре, не заголовок страницы, не форма комментариев внизу, а именно пост. Без поста эта страница бессмысленна».
Три состояния программы.
«Для каждого экрана вы должны рассмотреть три состояния:
- Обычное
Экран, который люди видят каждый день при работе с приложением, заполненным данными.- Пустое
Экран, который люди видят при первом запуске, и ещё не успели ввести данные.- Ошибка!
Экран, который люди видят, когда что-то идёт не так».
С самого начала.
«Создавайте ожидания, продумав то, какой опыт получит пользователь при первом запуске».
Защищайтесь.
«Посмотрим правде в глаза: неполадки обязательно будут происходить. Как бы тщательно вы не проектировали приложение, сколько бы времени не посвятили тестированию, у клиентов все равно будут случаться проблемы. Так как вы будете обрабатывать эти поломки? С помощью оборонительного дизайна.
[…]
Помните: ваше приложение может работать отлично в 90% случаев. Но если вы бросаете пользователей на произвол судьбы там, где ваша помощь им нужна – они вряд ли это забудут».
Содержание важнее целостности.
«Это нормально — сделать дизайн непоследовательным, если в этом есть смысл. Давайте людям то, что имеет смысл. Давайте то, что им нужно, и избавте от того, что лишнее. Уместность лучше последовательности».
Дизайн интерфейсов — это копирайтинг.
«Если вы думаете что каждый пиксель, каждая иконка, каждый шрифт имеет значение, вы поверите и в значимость каждой буквы. Когда вы описываете свой интерфейс, всегда смотрите на него глазами пользователей. Что они должны знать? Как это объяснить лаконично и доходчиво?»
Единый интерфейс.
«Cтраницы, содержащие системные настройки, списки пользователей и т.п., зачастую крайне неудобны и ужасно выглядят. Всё потому, что большая часть времени тратится на разработку основного интерфейса.
Не создавайте отдельного интерфейса для настроек, просто встройте его функции в основной».
Глава 10. «Код».
Меньший объем программы.
«Вам кажется, что имея в два раза больше кода, ваша программа будет только вдвое сложнее. На самом деле, каждый раз, когда вы увеличиваете объем кода, сложность программы возрастает экспоненциально».
Оптимизируйте для счастья.
«Счастливый программист — продуктивный программист. Вот почему мы оптимизируем удовлетворенность работой, и вам тоже стоит это делать. Выбирайте инструменты, базируясь не только на стандартах отрасли или производительности. Смотрите на неосязаемые факторы: чувствуется ли в инструменте страсть, гордость и мастерство? Будете ли вы по-настоящему счастливы, работая в этой среде восемь часов в день?
[…]
Вопреки общему мнению, языки программирования не равноценны. В то время как на любом языке можно написать практически любую программу, хороший язык сделает вашу задачу не просто возможной и терпимой, а радостной и дающей силы».
Говорит код.
«Прислушивайтесь к своему коду. Он будет высказывать предложения. Он будет сопротивляться. Он расскажет, где стоят ловушки. Он предложит новые пути решений. Он поможет вам держаться модели меньшего объема программы».
Разберитесь с долгами.
«Наваяли блок кода, который функционален, но все еще неопрятен – вот вы и набрали долгов. Набросали дизайн по принципу “и так сойдет” – ваши долги выросли опять.
Время от времени так поступать можно. Часто такая техника помогает поскорее довести проект в стиле Get Real до конца. Но все равно нужно признать эти долги и рано или поздно расплатиться с ними – вычистить неопрятный код, переделать ту страницу, которая была сделана так себе».
Открытые двери.
«Не пытайтесь запереть ваших клиентов. Позвольте им получить принадлежащую им информацию когда они хотят и как они хотят. Для этого вам придется отказаться от идеи запечатать данные. Выпустите их. Дайте людям доступ к их информации через RSS. Обеспечьте API, позволяющие другим разработчикам подсоединяться к вашей программе. Поступая так, вы облегчаете жизнь клиентам и расширяете возможности своей программы».
Глава 11. «Слова».
В функциональной спецификации нет ни грамма функциональности.
«Забудьте о спецификациях, подписанных раз и навсегда. Они заставляют вас принимать крупные, ключевые решения слишком рано в процессе разработки. Обойдите стороной стадию спецификации, и вам удастся быть гибкими и сделать изменения дешевле».
Не рождайте мертвых документов.
«Избегать функциональных спецификаций хорошо, но этого мало. Предотвращайте ненужное бумаготворчество везде, где можете. Если только документ не собирается воплотиться во что-то реальное — не создавайте его».
Расскажите короткую историю.
«Если вам нужны слова, чтобы описать новую функцию или изложить идею – напишите об этом короткий рассказ. Не углубляйтесь в технические или архитектурные детали, просто расскажите историю. Сделайте это на человеческом языке, как бы вы это сделали в разговоре».
Пользуйтесь обычными словами.
«Вставьте настоящий текст вместо lorem ipsum».
Очеловечьте ваш продукт.
«Подумайте о своем продукте как о человеке. Каким человеком вы бы хотели его видеть? Вежливым? Неумолимым? Прощающим? Требовательным? Веселым? Бесстрастным? Серьезным? Разболтанным? Хотите, чтобы он выглядел параноидальным или доверяющим? Всезнайкой? Или скромным и обаятельным?»
Глава 12. «Цена и регистрация».
Бесплатные образцы.
«Раздавайте что-нибудь бесплатно
Мир полон шума и суеты. Чтобы вас заметили среди всего этого, раздавайте что-нибудь бесплатно».
Легко войти, легко выйти
«Сделайте начало использования вашей программы — и окончание использования — как можно проще».
Раскраски.
«Все эти «Растишки», зайчишки и прочие завлекушки с наклейками и раскрасками — уловки для детей».
Подсластите пилюлю.
«Вам приходится объявлять плохие новости, такие как увеличение цены? Сделайте это как можно более безболезненным, сообщив об этом заранее. Также подумайте о том, чтобы освободить существующих пользователей от повышения цены на какое-то время. Эти люди обеспечивают вам хлеб с маслом, и вы хотите, чтобы они чувствовали себя уважаемыми, а не жертвами вымогательства».
Глава 13. «Продвижение».
Выпуск в голливудском стиле.
«Если выпустить программу в лесу, где ее некому использовать, произведет ли она фурор? Мы о том, что если выпустить программу без предварительной подготовки, то, скорее всего, никто о ней не узнает».
Мощный сайт для продвижения.
«Лучшее средство для продвижения продукта – сам продукт. Если вы создали приложение, которое действительно нужно клиентам, об этом непременно узнают.
Тем не менее, вам все равно нужен мощный сайт для продвижения. Что туда можно поместить?»
На волне блогов.
«Реклама стоит дорого. А оценка эффективности различных типов рекламы может оказаться дороже самой рекламы. Когда у вас нет времени или денег, чтобы пойти по традиционному рекламному пути, подумайте о другом пути: рекламируйте через блоги.
Начните с создания блога, который не только хвалит ваш продукт, но еще и предлагает полезные советы, решения, ссылки и т.д.»
Начинайте рекламировать как можно раньше.
Продвижение через обучение.
«Как технология продвижения, обучение – мягкий путь к тому, чтобы ваше имя – равно как и название вашего продукта – появилось перед множеством людей. И вместо того, чтобы заниматься навязыванием продукта, вы получаете внимание за предоставление ценной услуги».
Пища функциональности.
«Добавление новых или интересных функций — хороший способ усилить разговоры о вашем приложении. Группы по интересам очень любят пережевывать “пищу функциональности” и выплевывать ее обратно в сообщество. Ладно, аналогия не слишком аппетитная, но смысл вы поняли.
[…]
Небольшие команды идут на шаг вперед, когда дело касается воплощения новых идей в программы. Там, где более крупным компаниям приходится преодолевать бюрократические препоны, вы можете быстро воплотить новые идеи и снискать внимание за их использование».
Следите за логами.
«Вам полезно знать, кто о вас говорит. Проверьте свои логи и узнайте, что откуда берется. Кто на вас ссылается? Кто ругается? Какие из блогов, попавшие в списки на Technorati, Blogdex, Feedster, Del.icio.us и Daypop, говорят о вас?»
Продажи в процессе.
«Существующие клиенты – ваш наиболее перспективный рынок для дальнейших продаж. Не стесняйтесь развивать бизнес с теми, кто уже знает и использует ваш продукт».
На крючке названия.
«Многие совершают большую ошибку, когда считают, что название продукта должно быть сверхинформативным. Не стоит выбирать название, которое содержит детальное описание продукта. Обычно в результате выходит немудреное и легко забывающееся название. Название Basecamр лучше, чем что-то типа Project Management Center или ProjectExpress. Writeboard – лучше, чем CollaborEdit».
Глава 14. «Поддержка».
Почувствуйте эту боль.
«Избегайте постройки стен между вашими клиентами и командой разработчиков. Не передавайте техподдержки телефонному центру или сторонней организации. Осуществляйте ее сами. Вы, вся ваша команда, должны знать, что говорят ваши клиенты. Когда они недовольны, вы должны знать об этом. Вы должны слышать их отзывы. И вы тоже должны быть недовольны».
Нулевое обучение.
«Чтобы пользоваться сайтами Яндекса, Гугла или Озона, вам не нужны учебники или справочники. Почему бы вам не создать продукт, которому они тоже не нужны? Стремитесь создать продукт, не требующий обучения».
Отвечайте быстро.
«Пользователям нравится прямота, и часто их недовольство на глазах превращаются в вежливость, когда вы отвечаете быстро и прямо».
Трудная любовь.
«Будьте готовы сказать “нет” своим пользователям
Когда дело касается запросов и пожеланий о добавлении новых функций к программе, клиент не всегда прав. Если бы мы добавили каждую функцию, когда-либо предложенную нашими пользователями, наши продукты были бы никому не нужны.
[…]
Добавим к вышесказанному: крайне важно, чтобы вы, как компания-разработчик, любили свой продукт. А вы не сможете его любить, если он наполнен кучей вещей, с которыми вы не согласны. И это еще один довод в пользу того, чтобы отказать пользователям в выполнении запросов, в необходимость которых вы не верите».
В хорошей компании.
«Форумы и сетевые групповые чаты – хороший способ дать пользователям возможность задавать вопросы и помогать друг другу. Путем убирания посредника — то бишь вас — вы обеспечиваете открытый поток общения и экономите свое время».
Публикуйте ваши неудачи.
«Выпустите плохие новости и уберите их с дороги
Если что-либо пошло не так, расскажите людям. Даже если они не заметили».
Глава 15. «После выпуска».
Быстрое обновление.
«Выпустите обновление через 30 дней после выпуска
Быстрое обновление показывает движение. Показывает, что вы прислушиваетесь к советам пользователей. Показывает, что у вас еще есть «порох в пороховницах». Оно дает вторую волну разговорам. Оно подкрепляет первоначальные положительные эмоции, связанные с вашим продуктом. Оно дает пищу для обсуждения и сообщений в блогах».
Продолжайте выпуск сообщений.
«Покажите, что ваш продукт живет – продолжайте блог продукта после выпуска».
Не бета, а лучше.
«В наши дни кажется, что все постоянно находится в бета-версии. Неумирающая бета-версия говорит пользователям, что вы не так уж и хотите выпускать завершенный продукт. Она говорит: “Пользуйтесь вот этим, но если оно несовершенно – это не наша вина”».
Не все ошибки в программе созданы равными.
«Если вы нашли ошибку в вашем продукте – это не повод впадать в панику. Все программы содержат ошибки, это просто неоспоримый факт.
Не нужно сразу же исправлять каждую ошибку. Большинство ошибок надоедливы, но не смертельны. Те, которые надоедливы, могут быть отложены. Ошибки типа “что-то тут выглядит не так” и подобные можно без ущерба отложить на некоторое время. А уж если ошибка ломает вашу базу данных – тогда, конечно, она должна быть исправлена немедленно».
Переждите шторм.
«Если раскачивать лодку, появляются волны. Когда вы добавляете новую функцию, изменяете правила или удаляете что-нибудь – реакции будут разными, и часто отрицательными.
Избегайте паники и желания быстро все поменять в ответ».
Не отставайте от соседей.
«Подпишитесь на новости и о своих продуктах, и о продуктах конкурентов (это всегда мудро – следить за передвижениями противника)».
Остерегайтесь монстра разбухания.
«С развитием событий не бойтесь противостоять разбуханию. Всегда будет соблазн расширять продукт в объеме. Но это делать не обязательно. То, что продукт растет и становится более зрелым – не должно значить, что и более сложным».
Двигайтесь по течению.
«То, что придает красоту сетевым приложениям – это их изменяемость. Вы не упаковываете программу в коробочку, поставляете пользователю, а потом ждете новой версии в течение многих лет. Напротив, вы можете вносить изменения по пути. Примите мысль, что ваша первоначальная идея могла быть не самой лучшей».
Глава 16. «Заключение».
Готово!
«Ну хорошо, вы это сделали! Надеемся, вы с нетерпением ждете момента, чтобы начать применять Getting Real в своих программах. Сейчас самое лучшее время, чтобы создавать отличные программы, используя минимум ресурсов. При наличии хорошей идеи, страсти, времени и навыков – выше только небо».
Воплощение.
«Каждый может прочесть книгу. Каждый может придумать идею. У каждого есть родственник, работающий веб-дизайнером. Каждый может завести блог. Каждый может нанять кого-то еще, чтобы вместе наваять какой-то код.
Разница между вами и всеми остальными в том, как хорошо вы воплощаете. Успех достигается именно безупречным воплощением».
Люди.
«Стоит еще раз повторить, что главный элемент построения успешного сетевого приложения — это люди, работающие над ним. Мантры, проектирование от эпицентра, меньшее количество кода и все остальные замечательные идеи ничего не значат, если у вас нет людей, способных воплотить эти идеи».
***
Мой вердикт после прочтения книги: читать стоит всем. Всем, кто в процессе работы или хобби что-то создает. Всем, кто работает в командах. Всем, кто работает с людьми. Хотя интересно читать эту книгу будет, пожалуй, все таки только тем людям, которые работают в области разработки ПО.