Средства и задачи

Пока что важнейшим открытием в бизнесе этого года для меня стала
терминология средств и задач.
У клиентов есть долгосрочные цели. Для их достижения нужно
решать задачи, для которых нужны средства.
Сервисные организации решают сразу задачи клиента,
не погружая его в средства. Яндекс метрика как-то собирает данные и
рассказывает клиенту, какие страницы посещались, где есть
проблемные места. Клининг просто оставляет после себя чистый офис.
Такие организации иногда могут дать SLA на свои услуги и в целом
довольно предсказуемо умеют возвращать всё в состояние «верните как
работало»
Экспертные организации очень хорошо ориентируются
в готовых средствах и могут за клиента обеспечить подбор средств.
Это очень важно, ведь выбор средств может быть чудовищным. Этот
класс организаций во многом существует из-за неполного доступа к
знаниям. Так, например техническая/экспертная поддержка у такой
компании (например это бывают интеграторы) зарабатывает на
ограниченном доступе к знаниям. Один из характерных паттернов
поведения таких организаций в том, что они работают с задачами, как
с заведомо имеющими решение, надо просто подобрать настройки и
комбинацию (т.е. поднять тайные знания). Такое возникает на фоне
того, что средства они берут у тех, кто их сделал, а с ними
всасывают и знания об их применимости.
А вот когда средств не хватает, их нужно создавать. Этим занимаются
инженерные организации. В экспертных они плохо
живут — разный темп жизни, могут быть внутри сервисных, но там у
них размыта их орг структура, а могут жить отдельной. Наша компания
Эрливидео — в чистом виде инженерная организация, создающая
средства для решения задач клиентов.
Не мы вещаем телевидение и пишем IP камеры, это делают наши
клиенты, но с помощью нашего софта.
В каком-то российском подразделении Хуавея количество эскалаций
тикетов технической поддержки наверх в Китай было менее 1%. У нас
количество обращений в техподдержку, заканчивающиеся тикетом в
редмайне порядка 30% Это расшифровывается на этом языке так:
техподдержка хуавея решает задачи клиентов и у них в 99% случаев
для этого есть все средства и знания. У нас же обращаются в
поддержку, когда средства не решают какие-то новые задачи (ведь
старые то решаются) и техподдержка фиксирует в виде новых знаний о
рынке, о задачах клиентов в 30% случаев.
Т.е. у нас даже техническая поддержка работает с другими
функциями, чем в сервисной организации.
Из обихода автоматически выкидываются такие термины как «фичи»,
«баги».
Фича — это такая доработка средств под новую
задачу, которая воспринимается клиентом без негативных эмоций. Но
разговор про «а сделайте мне такую фичу» мы теперь переводим в
«какие у вас задачи, что вам не хватает того, что уже есть». А раз
не хватает, то скорее всего задачи новые.
Баг — это чаще всего такая фича, которая
воспринимается клиентом негативно. Он ожидал, что наше средство
подойдет под его задачи, а оно не подошло и он расстроен. В любом
случае сначала надо выяснить его задачи и только потом кидаться
жечь миллионы денег на создание нового средства.
Регрессия — это когда мы вообще не знали о задаче
и что-то сломали, а клиент пришел и ругается: говорит вчера его
задача решалась, а сегодня нет. Значит ему это реально нужно (иначе
не пришел бы), а мы не знали о задачах. В отличие от «бага»,
который ещё непонятно будет ли кому-то всерьез нужен, «регрессия» —
это подтвержденный business impact
С программисткой точки зрения тесты — это кодифицированные
знания о рынке, о его задачах.
Ещё очень важный момент напоследок.
Технари, будучи людьми глубоко эмоциональными (в отличие от очень
рациональных сейлзов и прочих т.н. гуманитариев), эмоционально
очень сильно прикипают к средствам. Отхватить в зубы за
неуважительное отношение к макросам емакса или дрелям хилти — да
почему бы и нет.
На переговорах технари устраивают бешеные срачи про
средства. Это эмоции, это подтверждение их экспертности.
Усомниться в средстве — это то же самое, что поставить вопрос
ребром: «а кто пустил этого задрота сюда за стол», даже если никто
вообще этого не имел ввиду. Спорить о средствах бессмысленно и там
можно только ломать людей, которые вам это припомнят.
А вот обсуждение задач проходит на порядки легче. Как только мы
переходим от средств к задачам, то сразу становится ясно, что
запускать постгрес на пошаренном через NFS каталоге,
экспортированном через plan9 fs из цефа не требуется. Ни в коем
случае нельзя говорить, что это плохое средство, достаточно просто
обсудить задачи и прийти к выводу, что сейчас пока до
таких материй не доросли.
В чём тут дело? Средства —
клевые, они блестят свежим хромом, от них пахнет
смесью спецдезодоранта, пластика и хрустом свежераспаковываемого
хельм чарта. Их хочется тащить в дом, посмотрите на свой
собственный шкаф с инструментами. Задачи —
мерзкие, их надо делать. Их все с радостью готовы урезать:
«хорошо, если мне машина нужна ездить к теще, то для раз в два
года, могу и не покупать её»
А дальше всё таки включается банальная логика: если предлагаются
средства, которые решают очерченный круг задач, то больше ничего не
нужно. А если очень хочется втащить что-то, то надо плясать от
задач. Правда иногда бывает нужно помочь клиенту, потому что не
каждый готов писать, что у него задача — купить себе квартиру с
отката, полученного за втаскивание в проект Netapp стораджа,
который дорогой, медленный и нахрен не нужен.
|
</> |