Батяня-комбат для разработчика: специально обученные чуваки, которые как консильери в мафии

в 7:57, , рубрики: Анализ и проектирование систем, Блог компании #tceh, знания опытного, куда копать, Тестирование IT-систем, трекинг

Батяня-комбат для разработчика: специально обученные чуваки, которые как консильери в мафии - 1

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

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

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

Ещё два коммита, и мы начнём делать бизнес! С понедельника!

Итак, большая беда проектов под руководством разработчиков — это то, что они тонут в текучке. В начале проекта все на энтузиазме, и кажется, что «Вот, мы сейчас полгодика поработаем, и все будет клёво». Проходит полгодика-годик, клёво не становится, зато становится тяжелее, потому что ты делаешь, делаешь, делаешь, а результат не виден. И самое главное: если ты не работаешь с пользователем, скорее всего, ты этого результата не увидишь.

Я понимаю, что писать продукт — это прикольно, комфортно. Ты сидишь, пишешь код, пробуешь новые инструменты. Хочется работать, вместо того, чтобы проверять на живых пользователях даже какие-то совершенно базовые функции. Часто возникает такая мысль: «Всю неделю мы пахали как проклятые. Результат не очевиден, но, может быть, он когда-нибудь проявится».

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

Нужен дебаг

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

Вот пример.

Как выглядит трекинг: пример с когортами

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

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

Трекер: Client ID присваивает Google, на сайте еще в первый момент, в первый раз он пришел, получил Client ID. Client ID ты спрашиваешь, в куку не лезешь, спрашиваешь java-script’ом на сайте: «Google, какой у него Client ID?» — «Такой-то» — «Окей». Запомнили в custom dimension.
Разработчик: Custom dimension — это что? Я сам беру из Google Analytics, кладу в Google Analytics?
Трекер: Да. Дальше что происходит? Когда он у тебя зарегистрировался, скачивает, например, ты спрашиваешь опять: «Какой Client ID?» — «Такой-то». Когда он регистрируется, в базу себе пишешь: «Этот чувак, — он тебе email ввел, — а Client ID из Google Analytics у него был такой-то», и в Google Analytics шлешь событие: «Чувак с таким-то Client ID, еще и с таким-то User ID, потому что у тебя появился его email, зарегистрировался». Ушло событие в Google Analytics потом.
Разработчик: И тогда ты знаешь всю историю?
Трекер: Потом он покупает, покупает он у тебя вообще в CRM, но ты когда его регистрировал, то положил себе в CRM Client ID, когда он регистрировался. В CRM событие покупки произошло, событие шлешь в Google Analytics, ты же помнишь его Client ID: «Чувак с таким-то Client ID, с таким-то User ID...».

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

Вообще, вопросы к трекерам бывают трёх типов:

  1. «Смотрите, какую мы придумали фичу. Закодим к концу недели. Что с ней делать дальше?»
  2. «Что-то мы уже полгода не растём. На жизнь хватает, но хочется роста бизнеса. Мы кодим-кодим, а результат тот же. Что делать?»
  3. «Кризис! Что делать?».

Здравствуйте, старший товарищ

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

Когда трекер сидит в том же здании — ты как маленький ребенок подбегаешь 10 раз на день и задаёшь простые вопросы из серии «почему лампочка светится», а в ответ он рассказывает быстро и доступно, так, что ты понимаешь суть. Бывает, конечно ты подбега-ешь со сложным вопросом «откуда берутся дети?» и тогда трекер с серьезным лицом ученого, рассказывает тебе, что мир не так прост. И, опять же, пробует донести основное. Такие разговоры и ценны больше всего.

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

Бывает, трекер помогает совершенно банальными советами, после которых всё начинает работать. Когда разработчики никак не могли запустить готовый сервис. «Папа» посоветовал раздать бесплатные аккаунты на пробу нескольким конкретным людям. Те стали использовать, получили нужные профиты… и запустили сарафанное радио. Другой сервис стартовал с месячной подпиской — там, опять же, после технических разговоров трекер предложил давать аккаунты на 1 день за 50 рублей — и заработало.

«Дебаг» проекта

Копая чуть глубже, трекер — это тот, кто помогает писать алгоритм развития бизнеса. Например, один из наших резидентов придумал такую историю: нужно сфотографировать своё запястье, чтобы получить информацию о своём размере одежды. Ну, знаете эту песню, когда мужик покупает штаны, и пробует посмотреть бирочку сзади на своих — выглядит очень весело. А у девушек другая проблема — то, что в одном месте M, может оказаться S в другом — чтобы подольстить немного, мол, в этом магазине я более худая. Так вот, вместо того, чтобы позволить закопаться в разработку, трекер просто отправил разработчиков в “Атриум”, ЦУМ, ГУМ, “Европейском” и другие торговые центры спрашивать, как часто люди ошибались с размером. Возможно, после этого тестирования, проект ждёт резкий поворот, а то и два.

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

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

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

У нас сейчас в #tceh «трекеров-пап», ведущих проекты, три штуки

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

Миша — программист со школы. Забил на МИФИ, пошёл в телеком админить и тянуть кабель в одну харю. Потом была своя студия: Миша кодил, ещё один товарищ рисовал, вместе искали клиентов. Потом стал работать один на фрилансе. Случайно попал на одну из первых стартап-тусовок Москвы. Там познакомился с парой хороших ребят — и они запустили GreenfieldProject. По сути, один из могикан, который развивает всю тему техно-логического предпринимательства эти годы. Хакатоны тоже пару раз соорганизовывал. Самый спокойный из трекеров (потому что мысль), он же отвечает за всю программу трекшнов в #tceh.

Женя — долго, методично и упорно — 11 лет — развивал свою ИТ-аутсорсинговую компанию. За эти годы, имея технический бекграунд, несколько раз уходил от управления бизнесом в техническую сторону: потому что если у тебя клиент федерального масштаба, а все кругом решают бюрократические вопросы, то Женя спешит на помощь. И так получилось, что все технические решения, которые он сформировал, используются до сих пор. И все бизнес-процессы — финансы, продажи, работа с людьми — им же отстроены. А ещё он стал очень въедливым — и его любимый приём — вывести проект из зоны комфорта — сказать: «а вот нифига у тебя это не так, чувак». В общем, он злой, но жутко полезный.

Пользователи не всегда честны с вами

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

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

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

Если вы думаете, что трекер помогает во всех трёх ситуациях, то жестоко ошибаетесь. Как у настоящего итальянского консильери мафии, задача трекера — не помочь своими руками, а заставить донов взглянуть на свою работу с другой точки зрения. То есть примерно в половине случаев трекер помогает проекту максимально быстро умереть. У того же Миши, например, руки по локоть в крови маленьких стартапят.
Потому что трекер вводит научный подход в ведение проекта. Построение гипотезы, её проверка, обсуждение, как получается быстро и дешёво проверить — или же кристаллизация понимания того, что проект представляет из себя шреддер. Шреддер, который захватывает инвестиции, перерабатывает их на мусор и снова получает, если повезёт (бывает и такое).

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

90% усилий не туда

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

Но это просто. Часто сложнее бывает выбрать, например, между «прекрати работать над сайтом и делай продукт» или «тормози с продуктом, сайт отстойный же, работай с ним».

Как правило, есть один трекер, который смотрит на проект в целом и оценивает целесообразность действий, и «узкоспециальные», которые могут помочь по конкретике — где-то нужно подсказать по технической части, где-то нужен аналитик и так далее. Вот, по-смотрите фрагмент с одной из трекинг-встреч. Здесь разработчики явно увлеклись кодом и продуктом, когда как можно было просто брать и продавать:

Вот ещё пример

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

— Если у меня увеличится трафик, то у меня захлебнется поддержка, потому что саппорт обрабатывает 60-70% тикетов, а 40% поднимаются до меня.
— Техподдержка — это у тебя девушка, которая frontline?
— Да, frontline. Она frontline прокаченный. Она с английскими скиллами более-менее, плюс она тестер изначально, она умеет устанавливать, она знает Linux, Windows, может поставить все это, и может ошибки отследить. И она общается с клиентами. Я обещаю поддержку только платным клиентам. Логику сейчас объясню свою. У меня есть эти лайт-версии, которые, по идее, без поддержки, но если мне пишут: «Я лайт-версию скачал, и не могу ее поставить, она выдает ошибку при установке»…
— Скачай платную версию, и мы тебе поставим её.
— Так жестко?
— У тебя техподдержка — это узкое место, которое тяжело расшивать, потому что пока ты людей найдешь, пока обучишь, пока что — долго и дорого. Поэтому прежде, чем это делать, нужно сделать эффективность системы максимальной при условии этого ограничения. У тебя на деньги влияет в этом месте то, получили ли поддержку платники, и получили ли поддержку те, кто станет платником. В первую очередь, влияет именно второе. Соответственно, задача — научиться давать поддержку тем, кто станет платниками, и не давать всем остальным, то есть пассажирам, отсечь пассажиров.
— А как делать лучше?
— Как только у тебя тикет должен подниматься на тебя, он обрубается, если он бесплатный. «Окей, чувак, это сложный тикет. Мы сложные тикеты только платным пользовате-лям обрабатываем. Хочешь сложный тикет — заплати денежку». И второе — у саппорта должен появиться шаблон.
— Он сам себе может делать шаблон.
— Ты должен написать такой шаблон.

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

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

«Доктор, что это со мной?»

В основном, трекеры нужны тем, кто уже знает, что делает («как копать»), но нуждается в общей помощи относительно того, «куда копать». С учётом, что большая часть проектов оплачивает трекинг из своих личных денег, можно утверждать, что это более чем необходимо. Лучше потратить 20 тысяч рублей на старте, чем полгода рыть в никуда.

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

Вот как-то так. Если интересно больше про трекеров и то, как попасть именно к нашим без того, чтобы сидеть в #tceh — вот ссылка. Если коротко — первая встреча бесплатная. Раньше пробовали по скайпу, но не канает, оптимально работает только лично. На этой встрече два трекера пытаются понять, нужно ли вам вообще это всё именно вам, и может ли помочь наша методология. Чтобы не было такого, что трекер как психоаналитик слушает, потом берёт деньги и говорит: «Ну, работайте усерднее». И вы страхуетесь от такого, и мы знаем, что работа не пойдёт в пустоту (да, можем и отказать, если считаем, что трекшн не нужен — или если вдруг вы сами поймёте, что фраза про «кровь молодых стартапов» — это, внезапно, про вас).

Автор: flashbackflip

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js