Купить в books.ru или ozon.ru

• Книга «Waltzing with bears: managing risk on software projects», в русском издании «Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения»
• Авторы Tom DeMarco (Том Демарко) и Timothy Lister (Тимоти Листер)
• Год издания 2005
• Автор рецензии Алексей Петров aka Sq.Piglet

Об авторах

Том Демарко — известный специалист в области управления проектами, автор нескольких книг и множества статей о менеджменте, глава консалтинговой компании Atlantic systems guild.

Тимоти Листер — преподаватель, журналист и консультант в области управления рисками и проектами по разработке ПО. В соавторстве с Томом Демарко написал несколько бестселлеров об управлении проектами.

О книге

Вальсируя с медведями — очень интересная книга об управлении рисками в проектах. Подход, описанный в книге, схож с подходами стандарта PMI PMBOK. В книге присутствуют готовые шаблоны и инструменты для управления и оценки рисков. Приведены и подробно разобраны примеры печально известных проектов и проявившиеся в них риски.

Для меня самой интересной мыслью в книге — стала мысль о том, что заказчик должен обосновывать и прогнозировать прибыль от проекта также ответственно, как и ПМ прогнозирует и отвечает за сроки и ресурсы.

Об издании

Из достоинств данного издания («Вальсируя с медведями: управление рисками в проектах по разработке программного обеспечения» Москва, p.m.Office, 2005), следует отметить хороший перевод, не плохую бумагу и твердый переплет.

Купить в books.ru или ozon.ru

• Книга «Peopleware. Productive projects and teams», в русском издании «Человеческий фактор: успешные проекты и команды»
• Авторы Tom DeMarco (Том Демарко) и Timothy Lister (Тимоти Листер)
• Год издания 2011
• Автор рецензии Алексей Петров aka Sq.Piglet

Об авторах

Том Демарко — известный специалист в области управления проектами, автор нескольких книг и множества статей о менеджменте, глава консалтинговой компании Atlantic systems guild.

Тимоти Листер — преподаватель, журналист и консультант в области управления рисками и проектами по разработке ПО. В соавторстве с Томом Демарко написал несколько бестселлеров об управлении проектами.

О книге

Человеческий фактор самая главная книга о менеджменте и ее обязательно читать всем руководителям.

Если коротко передать смысл книги, то получится так: неважно какие методологии и процессы вы используете, когда создаете проект, важно как вы относитесь к своим людям. Доверяйте своим людям и любите их, остальное они сделают за вас.

Эти простые принципы, к сожалению, многим не понятны. Зато те, кто разделяют эти принципы, создают легендарные команды и продукты.

Об издании

Из достоинств данного издания («Человеческий фактор: успешные проекты и команды» СПб., Символ-Плюс, 2011), следует отметить хороший перевод и не плохую верстку.

Недостатки: мягкая обложка.

Купить в books.ru или ozon.ru

• Книга «The Deadline a novel about project management», в русском издании «Deadline. Роман об управлении проектами»
• Автор Tom DeMarco (Том Демарко)
• Год издания 2011
• Автор рецензии Алексей Петров aka Sq.Piglet

Об авторе

Том Демарко — известный специалист в области управления проектами, автор нескольких книг и множества статей о менеджменте, глава консалтинговой компании Atlantic systems guild.

О книге

Книга написана как приключенческий роман, что является очень необычным жанром для книг такого рода. Действия происходят в одной из бывших стран соц. блока, которую купил один известный миллиардер по имени Бил, организовавший в стране огромный проект по созданию ПО. В этот проект и был приглашен руководителем главный герой.

Повествование проходит через все жизненные стадии проекта от найма персонала до прощальной вечеринки. В конце каждой главы автор, от лица главного героя, перечисляет извлеченные уроки.

Я нашел в книге несколько здравых идей, о которых раньше лишь догадывался, а сейчас применяю их на практике.

Об издании

Из достоинств данного издания («Deadline. Роман об управлении проектами» Москва, «Манн, Иванов и Фербер», 2011), следует отметить хороший перевод и верстку, отличную бумагу и твердую обложку.

Купить в books.ru или ozon.ru

• Книга «Управление проектами на основе стандарта PMI PMBOK»
• Автор Павлов А. Н.
• Год издания 2011
• Автор рецензии Алексей Петров aka Sq.Piglet

Об авторе

Александр Павлов — имеет степени PMP и PME, кандидат технический наук. Руководитель консалтинговой компании PM expert — одной из лидеров в своей области.

О книге

В книге изложена методология PMI PMBOK 2008 и ее авторская интерпретация, а также практический опыт автора по ее применению. Каждая часть книги описывает одну из девяти ключевых компетенций менеджера проектов из стандарта PMI PMBOK, а каждая глава конкретный процесс. В конце каждой главы приводится список извлеченных уроков, а в конце каждой части бизнес-кейс.

Эта книга вполне подойдет для изучения стандарта PMI PMBOK и для подготовки к экзамену на степень PMP. Книга является отличной альтернативой официальному изданию, да и стоит почти в 20 раз дешевле.

Об издании

Из достоинств данного издания («Управление проектами на основе стандарта PMI PMBOK» Москва, Бином, 2011), следует отметить твердый переплет, хорошую печать и бумагу.

Недостатки: посредственная верстка.

Купить в books.ru или ozon.ru

• Книга «The mythical man-month», в русском издании «Мифический человеко-месяц»
• Автор Frederick P. Brooks. Jr. (Фредерик Брукс)
• Год издания 2010
• Автор рецензии Алексей Петров aka Sq.Piglet

Об авторе

Фредерик Брукс — профессор вычислительной техники, «отец» IBM 360 и ряда других крупных продуктов компании IBM. Награжден национальной медалью в области технологий. Признанный авторитет в области IT-технологий и менеджмента.

О книге

«Мифический человеко-месяц» — классический труд об управлении IT-проектами. Первое издание увидело свет в 1975 году и позднее было переиздано более 20 раз! Последнее издание вышло в 1995. Несмотря на солидный возраст, книга до сих пор не потеряла своей актуальности. И хотя, некоторые главы, посвященные технической стороне вопроса безнадежно устарели, большинство информации до сих пор актуально. Удивительно, что многие полезные практики и методологии в IT-менеджменте были известны и применяемы в 60-х годах прошлого века. Удивительно и то, что почти все прогнозы данные Бруксом сбылись.

Основные тезисы книги:

• Увеличение количества разработчиков в опаздывающем проекте, как правило, увеличивает, а не сокращает срок разработки.
• «Серебреной пули нет» — в ближайшее десятилетие не появится способа увеличить продуктивность работы программистов, хотя бы на порядок.
• Основная задача менеджера это обеспечение правильной коммуникации в проекте и создание благоприятной среды для работников.

Я рекомендую начинать чтение профессиональной литературы о IT-менеджменте именно с этой книги.

Об издании

Из достоинств данного издания («Мифический человеко-месяц» СПб., Символ-Плюс, 2010), следует отметить хороший перевод и не плохую верстку.

Недостатки: мягкая обложка и черно-белые иллюстрации.

Симптомы кризиса в IT-подразделении

Работая в нестабильной внешней среде, с постоянно меняющимися требованиями к продукту, многие проекты погибают или превращаются в отделы, занимающиеся не проектной, а операционной деятельностью с постоянной сменой приоритетов и задач.

Особенно часто такая ситуация наблюдается в компаниях где IT-подразделение не приносит прямую прибыль, а лишь обслуживает различных внутренних заказчиков. Изменения в проектах такого IT-подразделения, как правило, носят сумбурный характер, а в работу принимается задачи тех заказчиков, у которых громче голос и за спиной больше власти. Но и эти задачи не доводятся до ума, так как на место предыдущего заказчика тут же приходит другой и «аргументированно» доказывает, что именно его задачи самые важные.

Заканчивается это обычно печально и для команды разработчиков и для самой компании. Отсутствие планирования, постоянная смена приоритетов, не стабильная архитектура, нехватка времени на исправление серьезных ошибок и рефакторинг, приводят к лавинообразному нарастанию энтропии и в конечном итоге к признанию результатов не удовлетворительными, как заказчиками, так и исполнителями. Обычно, после этого возможно два сценария: ядро команды переходит в другую компанию или команду просто увольняют.

Далее разработку в лучшем случаи отдают на аутсорсинг, а в худшем нанимают новую команду, которая повторяет историю предыдущей. Я знаю компании, в которых такие циклы повторялись до трех раз.

В конце концов, либо руководство компании начинает понимать, что дело не в разработчиках, а в собственном менеджменте, либо появляется сильный менеджер проектов, которому хватает ума и смелости объяснить «топам» их ошибки.

Создание проектного комитета для выхода из кризиса

Если вы оказались в роли менеджера проектов в подобном окружении и хотите исправить ситуацию, у вас есть только один путь — создать проектный комитет.

Проектный комитет — это совещательный орган, существующий в компании для принятия решений по проектам, приоритетам проектов и изменению содержания проектов.

Создание проектного комитета поможет стабилизировать внешнюю среду, расставить приоритеты между проектами и работами внутри них, увеличить ресурсы и в конечном итоге положительно скажется на деятельности не только вашего подразделения, но и всей компании.

Вот список шагов, которые необходимо предпринять:

1. Опишите текущее состояние дел

Опишите симптомы, проблемы и дайте прогноз на будущее. Вы и все заинтересованные лица должны четко осознавать опасность ситуации.

2. Определите список заказчиков и заинтересованных лиц

В этом списке нужно указать: всех заказчиков, силу их заинтересованности в вашей работе, степень влияния внутри компании и их отношения к вам.

Выделите группу, в которой окажутся те, кто: наиболее заинтересован в работе вашего подразделения, имеет высокое влияние и хорошо к вам относится. Постарайтесь увеличить эту группу перед созданием проектного комитета. Умасливайте недовольных, даже в ущерб своим текущим интересам. Это временная мера сильно поможет вам при создании проектного комитета.

3. Создайте формальный документ, описывающий регламент деятельности проектного комитета

Вот пример такого документа из моей практики:

Регламент работы проектного комитета

Описание деятельности

Проектный комитет — совещательный орган, обрабатывающий и систематизирующий запросы на разработку и изменение ПО и IT-инфраструктуры компании.

В проектный комитет входят представители заказчика (заказчиком может выступать начальник отдела или департамента) и представители исполнителя.

Область ответственности

Проектный комитет отвечает за: распределение IT-ресурсов между задачами и проектами компании; изменение приоритетов, целей и содержания уже запущенных проектов.

Все запросы на изменения и новые проекты для IT-департамента должны проходить утверждение проектным комитетом.

Инициация изменений содержания или нового проекта

Для инициации нового проекта или изменений в текущем проекте нужно подготовить следующую информацию:

1. «Устав проекта» — документ, кратко описывающий суть, цели и предварительный бюджет проекта.
2. Прогноз прибыли — модель монетизации или описание источника прибыли, график окупаемости инвестиций и т.; д.
3. Справку от аналитика — можно ли добиться целей проекта уже существующими инструментами.
4. Предварительную оценку сроков от исполнителей.
5. Оценку возможностей аппаратной части.

Члены проектного комитета

Заказчики: список заказчиков.

Исполнители: список исполнителей.

Алгоритм принятие решений

Принятие решений должно происходить на основе оценок потенциальной прибыли и трудозатрат. При обсуждении и голосовании обязательно должны присутствовать, как исполнители, так и заказчики, а также те участники проектного комитета, чьи интересы затронет изменение приоритетов.

Для получения дополнительной информации комитет вправе приглашать любого работника компании, а так же привлекать сторонних экспертов.

Принятие решений происходит голосованием. Для кворума достаточно присутствия 7 из 10 участников проектного комитета.

Результаты работы комитета

В случаи принятия отрицательного решения по новому проекту или изменениям, на выходе должен появиться документ с описанием причин, по которым проект или изменения были отвергнуты.

Если было принято положительное решение, то перед началом разработок заказчик вместе с исполнителем должны подготовить документацию и план работ по проекту.

Этот документ может и должен отражать специфику вашей компании.

4. Подготовьте почву

Поговорите с людьми, имеющими влияние в IT-подразделении, воспользовавшись данными из первого шага, постарайтесь убедить их поддержать вас. Тут проблем быть не должно, ваши коллеги сталкиваются с теми же проблемами, что и вы и, скорее всего, разделяют ваши взгляды.

Промойте мозги заказчикам. Это уже значительно сложнее, тут вам пригодится описание проблем (первый шаг) и список лояльных к вам и влиятельных в компании людей (второй шаг). Не пытайтесь давить на них и не торопите события. Действуйте исподволь. Например, приходит к вам начальник финансового отдела и говорит — «Когда вы приступите к разработке системы отчетов для нашего отдела?». А вы ему отвечаете — «Я бы с удовольствием, но вот Петя из отдела продаж заставил нас заняться редизайном сайта компании. Вот бы нам, что-нибудь придумать, чтобы точно понимать приоритеты между задачами разных отделов».

5. Проведите презентацию своих идей

Соберите заинтересованных людей, определенных на втором шаге и проведите презентацию своих идей. Проследите, чтобы на презентации обязательно присутствовали ваши влиятельные соратники из IT-департамента. Если вы боитесь, что есть люди, которые вас не поддержат или того хуже будут саботировать вашу деятельность, то не приглашайте их на первую презентацию.

Скорее всего, результатом первой презентации станет значительное изменение черновика регламента проектного комитета (шаг 3). Это даже хорошо, во-первых, скорее всего вас просто дополнят и укажут на ошибки, а, во-вторых, у всех присутствующих появится чувство сопричастности.

Вторую встречу проводите в том же составе и постарайтесь утвердить измененный по результатам первой встречи регламент работы проектного комитета.

На третью встречу пригласите всех лиц, определенных на втором шаге, даже врагов. Теперь вас будут поддерживать все, кто был на первых двух встречах. Они помогут убедить остальных.

6. Добейтесь подписания регламента и формального создания проектного комитета

Обязательно подпишите «бумажки» (приказ о создании проектного комитета и регламент его деятельности) на самом верху — это ваша индульгенция. Воспользуйтесь влиянием заинтересованных и положительно к вам настроенных лиц (шаг 2).

7. Проведите первое заседание

На первом заседании «разгребите» текущие задачи и добейтесь, чтобы заказчики четко расставили приоритеты между проектами и задачами. Возможно, некоторые проекты и задачи придется заморозить или закрыть. Именно на первом заседании столкнутся интересы всех заказчиков, постарайтесь абстрагироваться от их споров. Просто давайте оценки трудозатрат и напоминайте о доступных ресурсах.

Протоколируйте и исполняйте решения, принятые проектным комитетом. Не проводите заседания проектного комитета чаще, чем раз в две недели, а лучше проводите его только по требованию заказчиков.

8. Пропускайте все серьезные изменения только через проектный комитет

Все новые проекты однозначно должны проходить через проектный комитет. Все изменения в содержании существующих проектов должны быть вами оценены. Если ваша оценка отрицательная (т. е. изменение навредит проекту), но с ней не согласен инициатор изменения, то посылайте его в проектный комитет. Если ваша оценка положительная и изменение содержания проекта положительно скажется на проекте, то провидите оценку глобальности изменения. Глобальное изменение увеличивает сроки и бюджет проекта, целесообразность такого изменения должен определять проектный комитет. Самостоятельно принимайте в работу полезные и не глобальные изменения.

Приучайте заказчика к мысли, что старт новых проектов и внесение изменений в содержание существующих это зона ответственности проектного комитета, а не ваша.

Выводы

Проведение структурных изменений в компании, особенно снизу — задача не простая. Создание проектного комитета может занять не один месяц. Будьте терпеливы и настойчивы.

А что делать, если ничего не получилось? К сожалению, совет только один — меняйте работу.

Тем не менее, даже там, где полноценное тестирование входит в цикл разработки, его часто организуют неправильно. В этой статье я расскажу, как должно быть организованно тестирование.

Что и как тестировать

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

Когда проект стартовал, и первый код уже написан, проверяйте все решенные задачи, пишите приемочные тесты на всю готовую функциональность. Обязательно проверяйте все новые версии, даже если они не пойдут в бой. Составляйте и актуализируйте план тестирования или чек-лист для каждого разрабатываемого продукта.

Определите опытным путем время, необходимое на тестирование новой версии, исправление найденных ошибок и подготовки к выходу исправленной версии. Учитывайте это время в своем календарном плане. Это время не константа. В начале проекта это может быть один-два дня, ближе к концу, когда основная функциональность будет уже написана, время на тестирование и исправление может достигать нескольких недель, а в конце проекта, по мере стабилизации кода, время на тестирование сокращается. Умножайте это время на два перед выпуском знаковых версий продукта.

Состав группы тестирования

В идеальной группе тестирования должны быть следующие роли: начальник отдела тестирования, специалист по автоматическому тестированию, специалист по нагрузочному тестированию, несколько специалистов по ручному тестированию, аналитик, технический писатель и юзабилити специалист.

Начальник отдела тестирования — распределяет ресурсы отдела между различными проектами, отвечает за сроки тестирования новых версий продуктов, принимает решение о соответствии продуктов принятым в компании стандартам качества.

Специалист по автоматическому тестированию — создает автоматические тесты на всю важную функциональность, отвечает за их актуализацию и своевременное выполнение (прогон автоматических тестов занимает много времени). Кроме этого данный специалист должен отвечать за создание тестового стенда и различного рода автоматизацию, например, за написание билд-скриптов. Обязательно выделите на эту роль отдельного человека, иначе он погрязнет в ручном тестировании.

Специалист по нагрузочному тестированию — мне сложно представить систему, для которой производительность и скорость реакции не была бы критична. Поэтому нагрузочное тестирование нужно начинать на самых ранних стадиях. Например, проверять наброски архитектуры и структуры базы данных на соответствие заявленным в начале проекта характеристикам производительности.

Специалистом по нагрузочному и автоматическому тестированию может быть один человек. Он должен иметь высокую техническую квалификацию, разбираться в особенностях используемых протоколов, базах данных и языках программирования. Обычно, такие специалисты дорого стоят, но поверьте, иметь в штате такого человека гораздо лучше, чем толпу студентов.

Специалист по ручному тестированию — автоматизировать все не возможно, машина не заменит человека. Руками пройтись по основным функциям и бизнес логике, проверить соответствие проекта техническому заданию и спецификации может только человек. Обычно на эту роль нанимают студентов старших курсов технических специальностей.

Аналитик — специалист предметной области и бизнес логики ваших продуктов. Это связующее звено между отделом тестирования, командой проекта и заказчиком. Он отвечает на вопрос, как должны работать продукты.

Технический писатель — пишет и актуализирует техническую документацию. Возможно, многие со мной не согласятся, но я считаю, что писать техническую документацию должны не разработчики, а специально выделенный специалист в отделе тестирования. Отдел тестирования является одним из основных потребителей документации, носителем знаний о проектах компании и интеграции между ними.

Разработчики должны использовать системы автодокументирования, пытаться заставить их писать документацию — это отличный способ получить плохо документированный продукт и конфликты в коллективе.

Юзабилити специалист — если ваш продукт имеет пользовательские интерфейсы, вам нужен человек, который будет проверять их соответствие ожиданиям пользователей. Конечно, по-хорошему, у вас в организации должен быть специализированый отдел проектирования и тестирования интерфейсов, но не все могут себе это позволить. Если вы наняли специалиста по пользовательским интерфейсам, но у вас нет специализированого отдела, то лучше ему работать в отделе тестирования, так он не будет зависеть от менеджеров проектов.

Главное, что работники отдела тестирования должны не просто констатировать наличие ошибок или не соответствие спецификациям, но и помогать разработчикам находить причины этих ошибок. Для этого специалисты по тестированию должны хорошо разбираться в предметной области, архитектуре проектов и всегда проверять окружение тестируемой функциональности.

Идеальный тестовый стенд

Создание правильного тестового стенда задача очень важная и не сложная, но, почему-то, многие ее игнорируют. Это приводит к серьезным ошибкам на всех уровнях: от архитектуры и дизайна, до производительности готового продукта. Пример: реальные заголовки в два раза длинней из-за этого разъезжается верстка; в боевой базе 2 миллиона транзакций, а не 100 из-за этого поиск работает медленно; реальное оборудование слабее машин разработчиков и т. д.

В результате, первая версия продукта может настолько не соответствовать ожиданиям, что время необходимое на доводку как бы готового продукта часто превышает время на его создание.

Вот три простых требования к тестовому стенду:

1. Тестовые данные должны отражать реальность. Если вы делаете новую версию уже существующего проекта, вы должны скопировать его базу данных, замаскировав секретные данные. Если вы делаете новый продукт, вы должны сгенерировать данные похожие на настоящие. Это не должно быть «бла бла бла». Вы даже можете начать наполнять базу реальными данными, до того как будут готовы средства их визуализации.
   Для синхронизации тестовой базы с боевой, для маскирования секретных данных и для наполнения базы фейковыми данными, разумно использовать скрипты. Тут-то вам и пригодиться специалист по автоматизации.
2. Тестовое оборудование должно соответствовать оборудованию, на котором будет работать боевая версия продукта. Не всегда это возможно, но, по крайней мере, архитектура тестового оборудования должна соответствовать, а производительность быть слабее. У меня в практике был пример, когда база данных и приложение находились на разных машинах, но стояли в одной стойке, соединенные очень быстрым каналом. А в бою оказалось, что машина с базой находиться в Америке, а с приложением в России. Нам многое пришлось переделать.
3. Программное обеспечение боевой и тестовой машины должно быть абсолютно одинаковым. Вплоть до версии ОС и всех программ. Не соответствие программного обеспечения тестовой и боевой машины порождает самые загадочные глюки.

Все сказанное выше верно и для машин разработчиков. Применить для машин разработчиков правила 1 и 3 не составляет труда.

Автоматизация тестирования

Как уже говорилось выше, автоматизация тестирования очень важная задача. Особенно в условиях нехватки ресурсов на тестирование.

Кроме написания своих скриптов и макросов используйте готовые инструменты. Например, для web существуют валидаторы, проверяющие все страницы сайта на соответствие спецификациям W3C, и программа Xenu, ищущая битые ссылки.

Не забывайте про юнит-тесты, хотя писать их должны разработчики, но запускать, при сборке новой версии, могут и специалисты отдела тестирования.

Независимый тестовый отдел

Во многих организациях и проектах, в которых я работал, группа тестирования входила в состав проекта и подчинялась непосредственно менеджеру проекта. Это в корне не правильно, так как приводит к конфликту интересов между менеджером проекта и специалистами по тестированию. Менеджеру хочется быстрее закончить проект и сознательно или нет, он склоняет тестировщиков к выпуску некачественного продукта.

Не зависимо от структуры вашей компании, состоит ли она из отделов или проектов, отдел тестирования должен быть независимым и иметь такой же уровень подчиненности как отделы разработки или проектные команды. Иначе говоря, менеджеры проектов и начальник отдела тестирования должны быть равны в правах. Это гарантирует отсутствие конфликта интересов и соответствие готовых продуктов заявленным в спецификациях стандартам качества. Кроме того, у вас появиться человек, который будет нести реальную ответственность за качество.

Купить в books.ru или ozon.ru

• Книга «Death march», в русском издании «Путь камикадзе»
• Автор Edward Yourdon (Эдвард Йордон)
• Год издания 2003
• Автор рецензии Алексей Петров aka Sq.Piglet

Об авторе

Эдвард Йордон — эксперт в области управления кризисными проектами, автор нескольких бестселлеров о программировании и управлению проектами.

О книге

«Путь камикадзе» — эта классическая книга по управлению кризисными проектами. В книге даны практические рекомендации как выполнить проект, не упав лицом в грязь и сохранив нервные клетки.

В условиях постоянно меняющейся внешней среды, высокой конкуренции в области разработки ПО, любой нормальный проект, может в одночасье стать кризисным. Прочтите эту книгу для того, чтобы распознать этот момент и вовремя вернуть проект в нормальное русло.

Тем более вам необходима эта книга, если вы уже работаете в кризисном проекте. И не забудьте, что бывают ситуации, когда уже нет смысла продолжать стоять на мостике тонущего корабля.

Об издании

Издание («Путь камикадзе» СПб., Москва, Лори, 2003).

Недостатки: мягкая обложка, плохая бумага и верстка.

Купить в books.ru или ozon.ru

• Книга «Rocket surgery made easy», в русском издании «Как сделать сайт удобным „Юзабилити по методу Стива Круга“»
• Автор Steve Krug (Стив Круг)
• Год издания 2010
• Автор рецензии Алексей Петров aka Sq.Piglet

Об авторе

Стив Круг — автор знаменитого бестселлера «Не заставляйте меня думать!». Известный специалист в области юзабилити-тестирования, имеющий собственную практику, читающий лекции и проводящий семинары по всему миру.

О книге

Книга является отличным практическим пособием для тех, кто хочет внедрить практику юзабилити-тестирование в своей организации или проекте, и главное сделать это дешево. Методы, предлагаемые Кругом, нельзя назвать академическими, но, тем не менее, можно считать идеальными, с точки зрения соотношения цены и результата. Так, например, предлагается использовать в сессии тестирования не более трех человек, но проводить ее в конце каждой итерации разработки.

Книга написана с юмором, в ней много практических советов и готовых шаблонов для проведения самостоятельного тестирования.

Об издании

Из достоинств данного издания («Как сделать сайт удобным „Юзабилити по методу Стива Круга“» СПб., Питер, 2010), следует отметить отличную верстку с цветными иллюстрациями.

Недостатки: мягкая обложка, не лучшая бумага, переводчик добавил в текст много отсебятины.

Каких-либо планов по изменению лицензии, закрытию общего функционала, прекращению поддержки для open source community нет и не будет. Продукт продолжит существование как free open-source c лицензией BSD.

Знаменитый быстрый web-сервер nginx был создан Игорем Сысоевым для компании Рамблер в 2004 году и с тех пор стал очень популярен среди администраторов высоконагруженных проектов. Nginx — лучшее и бесплатное решение для web-серверов, обслуживающих большое количество обращений. На nginx работает и наш проект.

Источник: sysoev.ru.