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