Руководства для настоящего

Аннотация

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

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

Читать книгу «Гибкое управление IT-проектами. Руководство для настоящих самураев» онлайн или скачать бесплатно в формате fb2

У всех посетителей бесплатной электронной библиотеки фб2.рф есть выбор, в каком виде читать книгу
«Гибкое управление IT-проектами. Руководство для настоящих самураев». Книгу можно скачать бесплатно и без регистрации на своё устройство в виде файла удобного формата fb2, который поддерживается всеми современными читалками для Android и
IOS. Таким образом, скачав книгу fb2, вы сможете читать её полную версию в привычном вам
приложении.

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

На этой странице вы можете ознакомиться с описанием книги «Гибкое управление IT-проектами. Руководство для настоящих самураев» от
автора Джонатана Расмуссона в
жанре зарубежная деловая литература. Книга издаётся на русском языке и была добавлена в
библиотеку 13.09.2014. Начать читать книгу бесплатно онлайн вы
можете по этой ссылке, а скачать книгу в формате fb2 можно тут.

Как мастера Agile делают выдающееся ПО

Jonathon

The Agile Samurai Rasmusson

How Agile Masrets Deliver Great Software

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

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

© 2010 Jonathan Rasmusson.

© Перевод на русский язык ООО Издательство «Питер», 2012

© Издание на русском языке, оформление ООО Издательство «Питер», 2012

Об авторе

Джонатан Расмуссон, опытный предприниматель и бывший консультант по гибкой разработке (agile coach) в компании ThoughtWorks, занимается консалтингом на международном уровне, помогая клиентам находить наилучшие пути совместной работы и взаимодействий. Если Джонатан не едет на мотоцикле на работу по лютому канадскому морозу, то в свободное время он ведет блог http://agilewarrior.wordpress.com, где делится своим опытом из области гибкой разработки.

Благодарности

Эта книга никогда бы не получилась, если бы не поддержка Таннис – любви всей моей жизни – и трех наших чудесных детей, Лукаса, Роуэна и Бринна, которые прошли вместе со мной весь этот путь.

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

Следует также упомянуть тех разработчиков-первопроходцев, на труд которых я опирался при написании книги. Это Кент Бек, Мартин Фаулер, Рон Джеффрис, Боб Мартин, Джошуа Кериевски, Том и Мэри Поппендик, Кэти Сьерра и чудесный коллектив компании ThoughtWorks.

И, разумеется, эта книга никогда бы не состоялась, если бы не невероятно плодотворное сотрудничество и вдумчивый подход, проявленные рецензентами и комментаторами: Ноэлем Раппином, Аланом Френсисом, Кевином Гиси, Джессикой Уотсон, Томасом Гендроном, Дэйвом Клейном, Майклом Сикорским, Дэном Нортом, Джанет Грегори, Санджай Манчиганти, Венди Линдеманн, Джеймсом Эвери, Робином Даймондом, Томом Поппендиком, Элис Тот, Иэном Дизом, Меган Армстронг, Рамом Сваминатаном, Хэзер Карп, Чедом Фурнье, Мэттом Хьюзом, Майклом Менардом, Тони Семана, Ким Шриер и Рихейлом Кристофом. Особая благодарность Ким Уимпсетт и Стиву Питеру за превосходное техническое редактирование и набор текста.

Спасибо вам, мама и папа, за то, что любите и вдохновляете меня.

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

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

Мастер-сэнсэй

Рад встрече с вами

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

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

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

Внутри коллектива вам предстоит освоить определенные навыки.

♦ Умение успешно подготавливать и запускать с пол-оборота собственный гибкий проект. Процесс должен быть настолько ясен, чтобы у вас вообще не возникало вопросов из области «на какой стадии находится работа?» и «как это называется?».

♦ Умение собирать требования, оценивать и планировать работу прозрачно, открыто и честно.

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

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

Как читать эту книгу

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

В части I дается краткий обзор гибкой методологии разработки и объясняется, как работают команды, использующие данную парадигму.

В части II рассказывается об одной из наиболее многообещающих деталей предлагаемого метода – о подборе средств, которые составят арсенал вашей команды при реализации проекта. Речь пойдет о так называемой стартовой колоде (inception deck).

Часть III посвящена отзывам пользователей о проектах, выполненных в режиме гибкой разработки. Здесь же рассказано, как построить первый свой план такого проекта.

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

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

Глава 3

Главное — никого не забыть

Многие проекты умирают в зачаточном состоянии. Обычно это происходит по одной из следующих причин:

♦ неумение задавать правильные вопросы;

♦ боязнь задавать сложные вопросы.

В этой части мы поговорим о мощной методике построения перспектив, которую условно назовем стартовой колодой (inception deck). Она помогает найти ответы на 10 вопросов, без которых лучше не начинать какой-либо софтверный проект. Испытав команду на данном этапе, вы узнаете, все ли нужные люди подобраны для проекта и в правильном ли направлении вы движетесь. Это произойдет еще до написания самой первой строки кода.

3.1. Из-за чего погибает большинство проектов

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

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

И проблема не в том, что нам не удалось прийти к общему мнению уже на старте (это естественно). Проблема в том, что проекты начинаются еще до того, как найдены все нужные люди.

Ошибочное мнение о том, что консенсус достигнут там, где его нет и в помине, губит большинство проектов.

Нам нужно сформулировать план, который:

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

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

Единственный способ выстроить такой план — не бояться задавать вопросы.

3.2. Не избегайте сложных вопросов

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

Как видите, начиная любое новое дело (то есть проект), вы имеете большой простор для постановки вопросов и при этом ничего не теряете. Можно задавать общие вопросы, например, как приведенные ниже.

♦ Насколько опытна ваша команда?

♦ Занимались ли вы такими вещами ранее?

♦ Сколько денег у нас в распоряжении?

♦ Кто отдает приказы в этом проекте?

♦ Не смущает ли вас ситуация, когда в проекте участвуют два аналитика и тридцать разработчиков?

♦ Перечислите проекты, для работы над которыми вам пришлось пригласить команду молодых специалистов, практически незнакомых с объектно-ориентированным программированием, и успешно переделать устаревшую систему мейнфрейма для работы с Ruby on Rails — и сделать все это с помощью гибкой методологии.

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

3.3. Знакомство со стартовой колодой

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

В компании ThoughtWorks такой подход часто используется для анализа той части первичных работ над проектом, о которой практически ничего не говорится ни в экстремальном программировании, ни в скраме. Речь идет о закладке проекта (project chartering). Мы знали, что глубокий шестимесячный анализ и упражнения в сборе требований нам не подходят, но не могли придумать какую-нибудь более легковесную альтернативу. И именно в таких условиях Робину Гиббонсу пришла в голову мысль о стартовой колоде: быстром, легком способе извлечения из проекта самой его сути и рассказа об общем понимании задачи всей команде и другим участникам проекта.

3.4. Как это работает

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

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

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

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

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

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

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

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

3.5. Сущность стартовой колоды

Ниже перечислены основные вопросы и упражнения, прорабатываемые на этапе концептуализации проекта.

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

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

3. Разработка оформления продукта. Если бы мы быстро листали журнал и наткнулись на рекламу нашего продукта или услуги, то что бы она нам сообщила, и еще важнее — согласились ли бы мы за это заплатить?

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

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

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

7. Что не дает нам покоя? Иногда в ходе выполнения проектов происходят неприятные вещи. Но если поговорить о них и подумать, как их избежать, то, возможно, все будет не так плохо.

8. Определение временных параметров. Сколько времени займет проект: три месяца, а может, шесть или девять?

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

10. Что нам требуется для достижения результата? Сколько времени будет длиться проект? Сколько он будет стоить? И какая команда нам нужна для реализации этого проекта?

Мы изучим стартовую колоду в два этапа. В главе 4 поговорим о том, зачем мы беремся за проект, а в главе 5 рассмотрим, как его реализовать.

Глава 4

Общее представление о ситуации

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

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

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

♦ Для этого нужно ответить на ряд вопросов.

♦ Для чего мы здесь собрались?

♦ Каково блицрезюме нашего проекта?

♦ Как будет выглядеть реклама нашего продукта?

♦ Чего мы не собираемся делать?

♦ Кто работает с нами в команде?

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

Но сначала зададим нашим спонсорам вопрос, зачем мы здесь?

4.1. Вопрос: зачем мы здесь?

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

♦ принимать оптимальные и осознанные решения;

♦ лучше выполнять работу, уравновешивая противодействующие силы и идя на компромиссы;

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

Задача сводится к тому, чтобы понять намерение начальника и сформулировать для себя, как достичь поставленной цели.

«Тойота»: компания, умеющая видеть и достигать

В замечательной книге The Toyota Way [Lik04] Джеффри Лайкер рассказывает историю о том, как однажды в 2004 году главному инженеру этой компании поручили переработать модель «Тойота-Сиенна» для североамериканского рынка. Чтобы почувствовать, как жители Северной Америки живут, работают и занимаются своими машинами, он с командой проехал на «Тойоте-Сиенна» по всем штатам США и Мексики, а также по всем провинциям Канады.

И вот что выяснилось.

• Североамериканские водители больше едят и пьют в машине, чем японские автомобилисты (так как в Японии обычно приходится ездить на более короткие расстояния). Поэтому в любой «Тойоте-Сиенна» есть центральный лоток и 14 подставок для чашек.

• На канадских дорогах более высокий поперечный уклон, чем в США (выгнутый в середине), поэтому при вождении очень важно контролировать скольжение.

• Сильные ветры, дующие в провинции Онтарио, требуют особого внимания к устойчивости автомобиля к боковому ветру. Если вы поедете куда-нибудь, где сильные боковые ветры, вас приятно удивит устойчивость и легкость в движении новой «Тойоты-Сиенна».

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

Идите и попробуйте сами

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

Пойти и посмотреть — означает растормошить команду и познакомить ее с той сферой, где будет происходить действие.

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

Войдите в курс дела, задавайте вопросы и ненадолго превратитесь в своего клиента.

Как понять заказчика

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

В книге Made to stick [HH07] Чип и Дэн Хиты рассказывают, как в компании Southwest Airlines обсуждали, включить ли в меню одного из рейсов куриный салат «Цезарь».

Когда был задан вопрос, позволит ли это снизить стоимость билета (этого хотел добиться главный исполнительный директор Хербс Келлехер), стало понятно, что добавлять куриный салат абсолютно бессмысленно.

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

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

4.2. Создание блицрезюме

10 причин взяться за выполнение вашего проекта

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

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

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

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

Блицрезюме — это и есть ваша «речь в лифте». В нем вы должны сформулировать свою идею за крайне короткий промежуток времени. Блицрезюме предназначены не только для завлечения рисковых предпринимателей-авантюристов. В форме такого резюме еще удобно кратко и точно описывать новые софтверные проекты.

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

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

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

3. Помогает вникнуть в суть дела. Блицрезюме, подобно лазеру, прорезает массу хлама и попадает в самое сердце проекта. Такая ясность помогает расстановке приоритетов и значительно улучшает соотношение «сигнал — помеха», то есть количество того, что действительно важно.

Теперь давайте рассмотрим шаблон для составления блицрезюме.

Шаблон блицрезюме

Существует несколько способов преподнесения блицрезюме. Тот, который предпочитаю я, взят из книги Джеффри Мура Crossing the Chasm [Moo91].

Для [адресат сообщения]. Объясняется, на кого ориентирован проект или кому он мог бы принести пользу.

Который [утверждение о необходимости или о предоставляющейся возможности]. Расширенное представление проблемы или потребности, стоящей перед клиентом.

Это [название продукта]. Проект начинается с присвоения имени. Название важно, так как оно помогает понять ваши намерения.

Относится к [категория продукта]. Объясняется, чем, по сути, является данный продукт или услуга и какова полезная нагрузка проекта.

Быть кратким нелегко

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

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

«Я написал бы вам еще короче, но у меня нет на это времени». — Блез Паскаль, «Письма к провинциалу», XVI.

И при этом [основная выгода, убедительная причина приобрести]. Объясняется, почему клиент не отказался бы купить в первую очередь именно этот продукт.

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

Наш продукт [объяснение основного положительного отличия]. Здесь мы помогаем почувствовать разницу и объясняем, что в нашем предложении особенного, чем оно лучше альтернатив, предлагаемых конкурентами. Это самое важное. Именно на данном этапе мы объясняем, почему стоит вложить деньги в наш проект.

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

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

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

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

4.3. Разработка оформления продукции

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

Возможно, мы еще долго не увидим полок супермаркетов, уставленных программными продуктами, которые заботливо упакованы в пластиковые коробки и сто́ят шестизначные суммы. Но в связи с этим возникает интересный вопрос. Если бы можно было купить программу в супермаркете, как бы выглядела ее упаковка? И — еще важнее — купили бы мы ее?

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

Как это работает

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

Этап 1. Мозговой штурм о достоинствах вашего проекта

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

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

Чувствуете разницу?

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

Этап 2. Создание слогана

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

♦ Acura — «За рулём или на ложе, а всё лучше помоложе»[5].

♦ FedEX — «Весь мир по расписанию»[6].

♦ Starbucks — «Рухни в прохладу»[7].

Чувствуете эмоции, заложенные в этих слоганах? Теперь расслабьтесь. Эти слоганы — одни из лучших, и ваш совсем не обязательно должен быть таким же профессиональным. Просто соберитесь с командой, выделите 10 или 15 минут на придумывание слогана и проявите свои творческие способности. Помните — ни один слоган не бывает чрезмерно банальным!

Этап 3. Разработка упаковки

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

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

Итак, переходим к оформлению упаковки!

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

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

Пришло время узнать, как дать клиенту представление о предполагаемом функционале нашего проекта.

4.4. Создание списка функций

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

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

Конец ознакомительного фрагмента.

Аннотация к книге «Гибкое управление IT-проектами. Руководство для настоящих самураев»

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

Гибкое управление IT-проектами. Руководство для настоящих самураев, Джонатан Расмуссон

  • Название: Гибкое управление IT-проектами. Руководство для настоящих самураев
  • Категория: Книги / Программирование
  • Страниц: 267
  • Просмотров: 433

Читать журнал Гибкое управление IT-проектами. Руководство для настоящих самураев, Джонатан Расмуссон онлайн или скачать бесплатно с Яндекс Диска. Этот журнал и похожие на него журналы находятся в разделе сайта: Программирование, журналы. Свежий номер журнала Гибкое управление IT-проектами. Руководство для настоящих самураев, Джонатан Расмуссон, доступный для бесплатного чтения и скачивания, опубликован специально для вас. Вы долго искали почитать что-то интересное, и наконец, нашли. Обязательно прочитайте и скачайте онлайн журнал: Гибкое управление IT-проектами. Руководство для настоящих самураев, Джонатан Расмуссон из раздела: Программирование, , и не забудьте посмотреть другие журналы, ничуть не хуже этого. Все журналы публикуются на сайте только по вашим желаниям, специально для вас!

Читать журнал Гибкое управление IT-проектами. Руководство для настоящих самураев, Джонатан Расмуссон бесплатно — полная версия

Гибкое управление IT-проектами. Руководство для настоящих самураев, Джонатан Расмуссон — описание и краткое содержание, читайте бесплатно онлайн на сайте all-journals.com

Понравилась статья? Поделить с друзьями:
  • Сонмил инструкция по применению таблетки взрослым от чего помогает
  • Принтер hp laserjet 1010 инструкция по эксплуатации
  • 2 гму форма инструкция по заполнению
  • Масло промывочное лукойл авто 4 л 19465 инструкция
  • Как сшить шторы на петлях своими руками пошаговая инструкция