Управление проектами » Статьи

Кривая опыта

Денис Журавлев — Mon, 01 Feb 2010 15:28:29 +0000

Вначале немного теории:

Кривая опыта (Experience curve) – термин, примененный в 1966 году компанией Boston Consulting Group.

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

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

Эффект кривой обучения

Если работники учатся выполнять задачу лучше, то смогут выполнить ее быстрее. Если накопленный опыт удваивается, то производительность труда может увеличиваться на 10-15%

Эффект специализации

По мере роста производства и числа работников, компания может позволить себе вводить специализацию. Если 2 человека выполняют одну и ту же задачу, можно разделить ее между ними. Первый выполняет одну часть задачи, второй другую половину. Поэтому каждый может выполнить свою часть задачи дважды. Согласно описанному выше эффекту кривой обучения, специализация позволит снизить на 10-15% время на выпуск продукции, или на 10-15% увеличить объем.

Если опыт удваивается одновременно со специализацией, то эти 2 эффекта произойдут одновременно, что может увеличить производительность на 20-30%

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

Практическое применение

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

Уровень команды

Очевидно, что одна и та же команда выполнит новый проект, аналогичный предыдущему, быстрее. Так как она уже сработалась, притерлась и выработала некие внутренние стандарты. Скорее всего, что примерно на эти же 10-15% (при условии что проект действительно аналогичный). Далее скорость выполнения типовых проектов будет расти незначительно – 7%, 3%, 2%, 1%. Однако суммарный эффект будет весьма ощутим. Дальнейшее увеличение производительности уже будет возможна только при внедрении новых технологий.

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

Уровень работника

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

Человек без опыта изготовит табуретку за 60 мин. Далее каждую последующую он будет изготавливать на 10% быстрее

Cкорость изготовления табуретки

Опыт (шт.)	0	1	2	3	4	5	6	7	8	9	10
Время	60	54	48,6	43,7	39,4	35,4	31,9	28,7	25,8	23,2	20.9

Человек с улицы (0 табуреток опыта) – 60 мин
Подмастерье (3 табуретки опыта) – 43,7 мин
Специалист (5 табуреток опыта) – 35,4 мин
Мастер (10 табуреток опыта) – 20,9 мин

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

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

Не всегда стоит нанимать мастеров, иногда будет достаточно специалиста, ведь зачастую это будет дешевле.

Про кривую опыта можно почитать тут:

Experience curve effects
Кривые опыта
О чем говорит кривая опыта?

Прибыльность проекта

Сергей Синькевич — Sun, 17 Jan 2010 20:34:19 +0000

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

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

Далее пробуем посчитать — насколько же ваш проект выгоден? :-)

Воспользуемся простейшим определением из википедии, гласящим о том что прибыль — это превышение в денежном выражении доходов от продажи товаров и услуг над затратами на производство и сбыт этих товаров и услуг. Существуют разные типы как учёта, так и классификации прибыли (бухгалтерская прибыль, экономическая прибыль, валовая прибыль, чистая прибыль). Однако, давайте для начала не усложнять, и рассмотрим простую формулу в виде разности двух упомянутых выше понятий: Прибыль = Доход – Затраты.

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

Давайте теперь посчитаем затраты на оказание этих услуг. Что же происходило? :) Программисты программировали, тестировщики тестировали, и так далее — обобщая, люди тратили рабочее время на заказчика. Зарплата всех работников, задействованых в проекте, суммарно составила 600 тугриков. И сколько же у нас получается прибыли для организации? 400 тугриков?

Конечно же, нет. Для начала давайте вспомним, что в прошедшем месяце мы дополнительно купили для нужд программистов специализированную программную компоненту, стоимостью 100 тугриков. Что ж, добавим её к затратам, проверим чтобы больше ничего не забыли — вуаля, получаем прибыль в 300 тугриков?..

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

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

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

Если у вас есть что добавить по этому вопросу — добро пожаловать в комментарии :-)

Исполнитель и многозадачность.

Денис Журавлев — Mon, 11 Jan 2010 19:09:33 +0000

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

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

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

Однако в результате переключений на выполнение каждой задачи потребовалось ~7 дней. Первый менеджер получил задачу на 4 дня позже чем мог бы, соответственно были задержаны другие задания связанные с выполненным далее по цепочке (тестирование, релиз и т.п.), была задержана оплата и т.п.

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

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

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

В заключение приведу несколько общих рекомендаций:

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

Менеджер и многозадачность

Сергей Синькевич — Sun, 10 Jan 2010 20:38:24 +0000

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

Достаточно много известных людей уже высказывались на эту тему. Приведу несколько ссылок:

Что ж, давайте попробуем самостоятельно взглянуть на этот аспект деятельности менеджера. Если взглянуть на ежедневную работу, выполняемую руководителем (например, менеджером проекта), то можно заметить, что переключение контекста происходит чрезвычайно часто. Работа с текущей почтой кажется однообразным занятием только для тех, кто не понимает что происходит. Мы же знаем, что каждое новое полученное или отправленное письмо представляет собой или новую задачу, или продолжение одной из старых. Сколько писем проходит через почтовый ящик среднего современного менеджера? 100? 300? Иногда это число измеряется не в сотнях, но в тысячах… А ведь еще есть работа с документацией, с различного рода системами таск-, баг- и ишью-трекинга. Каждый новый пункт, который мы открываем в такой системе — это новый контекст. Суммируя и усредняя, давайте будем считать, что в среднем число переключений будет равно 500.

Несложно посчитать что (8 часов рабочего дня * 60 минут) / 500 = около 1 минуты — это максимальное время переключения между контекстами, которое менеджер может себе позволить. А ведь еще необходимо провести обработку и регистрацию поступившей информации.

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

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

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

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

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

Бесплатный Хронометраж

Сергей Синькевич — Sun, 10 Jan 2010 18:19:28 +0000

Вновь подниму тему персональной эффективности, и напомню коллегам о пользе хронометража личного и рабочего времени. Чтобы не изобретать велосипед, дам ссылку на выдержку из книги известного гуру тайм-менеджента Глеба Архангельского: вот она.
Известно что любая идея чахнет без подходящего инструмента, поэтому в дополнение темы о программах измерения рабочих активностей по времени, позволю себе добавить бесплатный аналог, которым сам пользуюсь уже некоторое время: ManicTime.
По функциональности, из плюсов — возможность делать личные тэги по задачам/проектам (что реально очень удобно), интуитивно понятный интерфейс; из минусов — обьём потребляемой памяти (все-таки .NET :)

Московский метод

Денис Журавлев — Sun, 03 Jan 2010 21:44:04 +0000

Начну с истории из реальной жизни. Был у нас один заказчик, который предпочитал сам выставлять приоритеты требованиям и багам. Все начиналось классически — High, Medium, Low. Однако в какой-то момент он решил усовершенствовать эту систему и добавил Very High. Но со временем и этого оказалось мало, появился приоритет Urgent. Наверное, это может продолжаться и дальше.

В другом проекте, при приоритизации требований, использовались аналогичные приоритеты (1,2,3). И нам как разработчикам не всегда удавалось определить логику которая двигала людьми из бизнеса при приоритизации, особенно вызывал внутренний конфликт высокий приоритет юзабилити требований, при низких приоритетах функциональных.

Однако прогресс не стоит на месте. И один из консультантов Oracle UK Consulting, Dai Clegg предложил логичный и понятный метод приоритизации для бизнес анализа и разработки ПО — MoSCoW prioritization.

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

MoSCoW — легко запоминающаяся аббревиатура:

M — MUST have this.

S — SHOULD have this if at all possible.

C — COULD have this if it does not affect anything else.

W — WON’T have this time but WOULD like in the future.

Must have — Жизненно необходимые

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

Should have — Обязательные

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

Could have — Пожалуй можно реализовать

Требования COULD have менее критичные требования, обычно относящиеся к «nice to have». Чаще всего менее трудоёмки чем первые 2 категории.

Won’t have (but Would like) — Можно и не делать, но хотелось бы

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

Ссылки:

http://en.wikipedia.org/wiki/MoSCoW_Method

http://www.projectsmart.co.uk/moscow-method.html

http://www.coleyconsulting.co.uk/moscow.htm

Хронометраж вести стало легче!

Денис Журавлев — Fri, 12 Dec 2008 17:16:50 +0000

Нактулся в закромах интернета на интересную программу Slife.

Для установки скачал инсталяционный пакет в 400Kb с сайта, а после она еще выкачала себя (9Mb). Видимо исспользует ClickOnce.

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

Вот еще несколько аналогов,

TimeSnapper for Windows
RescueTime for OS X (also available for Windows)
Timecamp
Toggl
ActiveTimer

Еще одна родственная программа но которая делает снимки экрана через определенные промежутки времени TimeSnapper

Agile – это круто? Проверьте исходные предположения!

Денис Журавлев — Wed, 10 Sep 2008 14:37:33 +0000

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

Реальность такова:

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

2) Редкий заказчик умеет адекватно ставить задачи и приоритеты, поэтому, скорее всего, придется это делать вам самим.

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

5) ЮнитТесты как правило удорожают проект, что не всегда оправдано.

6) Отсутствие документации по проекту это всегда недостаток, а не достоинство.

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

8) Парное программирование это круто? — если бы это было так, однажды попробовав, все бы писали в парах.

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

MS Project трюки

Денис Журавлев — Mon, 09 Jun 2008 15:26:37 +0000

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

Итак, начинаем новый проект.

База ответьте

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

Я приверженец 2-го подхода. И для удобства сравнения с начальной версией удобно сохранить первоначальный план как baseline.

Сохранение base line: Tools >Tracking > Set Baseline… > OK
Просмотр baseline: View > Tracking Gantt

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

Явное указание отпусков и болезней

Также, при начальном составлении плана, и в дальнейшем удобно в плане отражать отпуска исполнителей. Тут тоже мне известно 2 подхода. 1) Изменять календарь исполнителя и выставлять не рабочие дни и 2) явно указать отпуск в виде задания. Это более наглядно. Также можно таким же образом вносить в план и болезни сотрудников.

Передвинуть задание

Иногда возникает необходимость передвинуть задание в плане которое уже частично выполнено. и при попытке изменить сроки происходит split задания на 2 выполненный. Кусочек остается на месте, а не выполненный двигается.

Для того чтобы избежать разделения задания и передвинуть его установите % complete в 0, перенесите задание, а затем выставьте заново % complete в старое значение.

Отношение к прогрессу

Я пользуюсь следующим принципом в выставлении % complete задание не начато % complete = 0% в процессе 50% и закончено 100%, любые высказывания, что задание готово на 87% считаю бессмысленными, если только эта цифра не рассчитана на основании % готовности сабтасков, т.е. в идеале нужно стремиться оперировать минимально разумными единицами работы. (Помните что первые 80% процентов работы выполняются быстрее чем оставшиеся 20%)

Боевая раскраска

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

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

Риски и внешние зависимости

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

Контрольные точки

Если план достаточно длительный, то контрольных точек в нём наберется достаточное количество. Для удобства их тоже можно вынести в отдельную группу. Также если вы не стартуете реализацию сразу после планирования, можно помещать в котрольные точки еще один пункт “Start Project A” и выставлять его как Predecessor у всего плана, т. о. мы сможем лекго сдвигать даты начала работ.

Семафор

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

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

Или можно воспользоваться более “модной” техникой.

1) Tools->Customize…->Fields.

2) Выбираем в выподающем списке Type: Duration

3) Жмем кнопку Formula… и вводим необходимую формулу

4) Далее жмем Graphical Indicators… И вводим необходимые условия и выбираем соответсвующие изображения.

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

5) Далее жмем на заголовке колонок правой кнопкой и выбираем Insert Column… и выбираем только что созданную колонку.

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

Также вы можете скачать пример в формате mpp (2007)

Полезные ссылки (English):
MS Project Templates
Help for Project 2007
Project 2007 Courses
Project Demos

А у вас не найдется в запасе пару хитростей чтобы пополнить этот список ?

Победить сегодня — значит проиграть в будущем

Денис Журавлев — Tue, 22 Apr 2008 16:12:03 +0000

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

Так зачем же связываться со сложными проектами, и работать с неадекватными клиентами? Может лучше подбирать хороших исполнителей, а не безумных креативщиков?

Давайте попробуем выяснить стоит ли напрягаться. Предположим мы уже имеем за плечами большой опыт. Перед нами появляется новый проект, очень похожий на те, 100 предыдущих, которые уже успешно выполнены. Круто! Мы беремся выполнять этот проект используя весь накопленный опыт и инструментарий, все идет гладко и мы заканчиваем его в сроки и даже не вышли за отведенный бюджет. Мы победители?

НЕТ !

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

Поэтому, выйграв все сражения, проиграем войну.

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

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

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

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

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

Специалист по рекламе Дэвид Огилви сказал: Моя фирма занимается только двумя вещами 1) обслуживанием клиентов и 2) развитием своих талантов в области рекламы.

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

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

Клиент — непревзойденный показатель качества.

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

Дэвид Огилви хвастался, что сам увольнял клиентов намного чаще, чем те увольняли его.

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

Ищите «крутых» клиентов, которые 1) определяют вас и 2) помогают вам расти. Инвестируйте в «крутых» клиентов, которые будут испытывать вас. И помогут вам вырасти в личном и профессиональном плане.

Книги по теме:
Том Питерс — Проект 50
Том Питерс — «Профессиональная сервисная фирма 50»