Для кого этот пост?

Это пост полезен для айтишников: разработчиков, менеджеров, дизайнеров и аналитиков.

Он поможет рядовым сотрудникам найти ответ на вопрос: «О чем болит голова у коллег?». Работникам выше по должности, напомнит, почему важен продукт, а не политические игры.

Почему стоит верить мне?

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

У каждого сейчас около 1М установок в Google Play. И несмотря на то, что ни одно из них так и не стало реально популярным и не принесло мне значительных денег, путь, который я прошел, создавая свои продукты, превратил меня из узкоспециализированного Android-разработчика в full-stack инженера, попробовавшего почти все роли айтишника (до определенного уровня, конечно).

Полезен ли этот опыт сейчас? Да, так как дает мне целостное представление о разработке продукта и помогает правильно оценить куда направить инвестиции и людей. Благодаря этому я могу спокойно справляться с обязанностями руководителя разработки в Profoto.

Работайте не много, а головой

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

1. Я перестал делать задачи, которые не несут никакой ценности. Теперь уверен, что всегда делаю, что-то полезное для пользователей и это дает мне энергию.
2. Я стал иначе относиться к багам.
3. Я не делаю релизы в пятницу ради релизов, а спокойно ухожу домой на выходные. В 99% случаев любая фича подождет до понедельника.
4. Я научился прислушиваться к опыту и рекомендациям команды. Особенно, когда они советуют упростить фичу, чтобы ее реализация заняла гораздо меньше времени. Или улучшить UX…
5. Я осознал насколько важна и нужна коммуникация с людьми.

Качество и баги

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

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

Самая яркая и запоминающаяся история произошла в 2016 году… Мы с друзьями делали приложение на хайпе по PokemonGo, оно приносило нам около 1000$ в день. Жировали мы около недели, пока гугл нас не забанил.

При чем тут качество и баги? Я вспоминаю ночь, когда обновил FB SDK, и, даже не запустив приложение на телефоне, выкатил апдейт в Google Play.

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

В таких ситуациях фраза «компания теряет бабки» перестает быть чем-то абстрактным и незначительным.

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

Приоритеты

Что важно сделать сейчас?

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

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

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

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

Вопрос «А какое value это принесет бизнесу?», который раньше воспринимался как шаблонный, вдруг заимел вес. Я начал задавать его себе каждый раз перед тем как взяться за задачу.

Важный, хоть и не очевидный факт:

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

Иногда, лучшей стратегией развития продукта после определенного этапа становится бездействие.

Продакт менеджмент. Что нужно делать, а что вообще не нужно.

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

На работе, я начал челенжить продакт менеджера вопросами: «А зачем нам эта фича? А какую пользу бизнесу она принесет? А что будет, если ее не внедрять?». Не из-за вредности, конечно. Я замечаю, что продакт менеджеры, как и разработчики, грешат внедрением фич ради фич.

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

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

Расскажу о методах, которые я открыл для себя.

Что мне помогает при оценке важности фичи?

Обычно при создании своего продукта в голове возникает нереальное количество идей и фич. Трудно избавиться от навязчивых мыслей по типу: «Нужно сделать это скорее», можно подумать будто завтра конец света.

Я стараюсь опираться на объективные данные:

1. Данные аналитики.
2. Юзер тесты
3. A/B тесты

Аналитика как инструмент продакт менеджера

Я — не эксперт в данной области, поэтому с удовольствием выслушаю ваши мнения.

В параграфе ниже вы сможете найти информацию о пользе аналитики и об объектах трекинга. Здесь же подсвечу, как аналитика помогает в продакт менеджменте с помощью двух ответвлений (по-моему мнению):

1. Работа с инсайтами
2. Работа с конверсией

Работа с инсайтами

Смотрим на использование отдельных фич продукта и пытаемся понять:

• Нужны ли они в принципе? Есть ли польза?

• Актуален ли наш дизайн?

• Можно ли что-то улучшить?

Мне очень нравится следующая аналогия:

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

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

Условно: улучшение конверсии всегда будет в приоритете, нежели улучшение утилитарных фич.

Работа с конверсией

Тут просто:

Все, что напрямую приносит компании деньги, будет в приоритете.

Аналитика помогает построить воронки конверсии и проследить user journey от начала использования до покупки. Можно представить, как обернётся улучшение конверсии на 1%  для компаний с оборотом 1M$/месяц.

Говоря «используйте аналитику», кажется я даю очевидный совет. Проблема в том, что я видел много компаний, которые используют аналитику только в формате «посмотреть количество daily active users».

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

Этот раздел затрагивает аналитику только с точки зрения продакт менеджмента. Про другие виды аналитики мы ещё поговорим позже.

Юзер тесты и обратная связь

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

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

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

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

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

A/B Тесты

Обычно, запуск A/B теста — это самый точный способ проверки гипотезы.

Ограничение A/B тестов: необходимо множество пользователей и данных, чтобы получать статистически значимые результаты.

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

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

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

Инвестирование в продукт

Как инвестировать в сферы, в которых ты не силён? Сайт, дизайн, маркетинг, SEO.

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

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

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

С рекламой все немного понятнее. Ты влил в свой продукт 100$ и если у тебя все хорошо с конверсией, вытащил 150$. Заплатил налоги и понял, что нифига не заработал. Дальше дело масштабов.

Всё значительно усложняется на стадии отсутствия ROI (return of investments).

Например, инвестирование в создание нового продукта.

С минимальными вложениями можно провалидировать идею, сделать лэндинг или опросить потенциальную ЦА. Тем не менее даже после этого неизвестно взлетит продукт или нет, а уже нужно оплатить услуги дизайнера (1000-2000$) и столько же в разработчика просто для получения MVP. Особенно грустно, когда твоя собственная зарплата не сильно выше.

Этот навык мне очень помогает в повседневных обязанностях менеджера мобильной разработки. Пусть в компании я распоряжаюсь «чужими» деньгами, но способность увидеть то, что за создание незначительной фичи или за рефакторинг твоя компания заплатила 10N тысяч $... Поверьте, это помогает с приоретизацией задач в бэклоге.

У меня до сих пор нет четкого понимания, как, будь это моя компания и мои деньги, эффективно инвестировать в разработку, когда ты не можешь адекватно просчитать ее стоимость, а разработчики разводят руками и говорят «ой, эстимейты — это сложно». Почему-то сразу вспоминается Егор Бугаенко и его Zerocracy.
Буду рад узнать ваши мнения!

Part 2. Менеджмент.

Как менеджить людей в областях, в которых ты некомпетентен.

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

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

О задачах

Когда я был простым разработчиком, мне было безумно трудно делегировать. Казалось: «Кто я такой, чтобы просить? А что если меня пошлют?»

Я всегда старался говорить о своих желаниях помягче. Что-то вроде «Может быть ты мог бы посмотреть на эту задачу?». Мое максимально "прямое" высказывание было "Можешь посмотреть эту задачу?".

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

Такая формулировка полностью обнуляет важность просьбы, у человека закрадываются сомнения: «Чего он хочет? Делать или нет?»

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

Что делать, если некомпетентен в какой-то области?

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

Представьте ситуацию: вы — фасилитатор митинга, на котором нужно организовать работу 3-х разных отделов: backend, mobile и marketing. Пусть у вас 15 лет опыта в IT и 10 из них вы работаете с бэкэндом.

Я думаю, что на таком митинге не стоит объяснять людям из других отделов, что и как они должны сделать, согласны?

Лучше обозначить, чего вы хотите достичь. Спросить, как бы они они могут с этим помочь?

При этом очень важно принять тот факт, что вы не можете знать все. Да и зачем? Ведь вы окажетесь в огромном плюсе, если грамотно воспользуетесь моментом. У вас два пути: набраться опыта и получить знания, либо сидеть и кивать, ничего не понимая, чтобы потешить эго.

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

Когда вам объяснят, попробуйте сделать summary, чтобы убедиться, что вы на одной волне. Ведь как неудобно будет, когда сделают совсем не то из-за недопонимания?

Как проверять прогресс?

Максимально прямо.

Мне кажется, достаточно тяжело понять того, кто ходит вокруг-да-около.

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

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

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

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

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

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

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

Техническая экспертиза

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

Это возможность попробовать себя в роли различного рода архитекторов: solution / application / data architect.

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

Если для интеграции какого-то server-side решения мне нужно 200 часов разработки, а, взяв условный Firebase, можно сделать тоже самое за 10 часов, кажется, выбор очевиден.

Проектирование системы целиком

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

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

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

На это наложились ограничения некоторых систем, которые я использовал. Например: мне не хотелось платить 100$/месяц за сервис-интегратор платежей с разных платформ. К чему это привело? Сейчас он не умеет оповещать мой сервер, когда кто-то совершил покупку.

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

Изучить новый язык

Я много лет работал на легаси проектах, где язык, фреймворк, подход и архитектуру определили за много лет до моего рождения прихода на проект.

Я не брался за проекты, для которых мне пришлось бы учить что-то с нуля, но... Сколько можно писать на Java?

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

Так выбор Flutter в качестве языка/подхода к мобильной разработке стал для меня очевидным. Банально, потому что у меня нет сил и времени писать два одинаковых приложения под iOS и Android на разных языках.

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

Кастомер сапорт

Проблемы пользователей, ответы на имейлы, отзывы в маркете и социалках

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

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

Это ли не чудо, когда диалог начинается с претензии «Ваше приложение ломает мой телефон!», а заканчивается положительным: «Воу, какая крутая фича, пойду куплю полную версию приложения!».

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

Если вы создаете продукт, попробуйте на одном из ваших ретро залезть всей командой на FB, VK, Insta или Reddit и почитать, что люди пишут о вас.

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

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

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

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

Аналитика

С момента запуска вашего продукта (в идеале до запуска) у вас возникнут мысли: «А как люди вообще используют мой продукт и много ли их? Нужны ли эти фичи?».

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

Что трекать и как

Во всех компаниях, где я работал, я встречал (увы) только неправильный подход к аналитике. Всегда в духе «давайте трекать все, а потом решим что нам надо».

Здесь две проблемы:

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

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

Пример из моего приложения для хранения паролей:

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

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

Какого же было наше удивление, увидеть, что уже на этом этапе отваливается примерно 20% пользователей. Увидев такой результат хочется бежать и оптимизировать.
Вот только вопрос, что именно оптимизировать? Базовая аналитика показала нам только факт проблемы, но не ответила на вопрос «почему?».

На этом этапе мы брейнштормим и строим гипотезы.

А что если:
— пытался зайти кто-то посторонний?
— человек забыл паскод?
— у них пальцы мокрые и отпечаток не работает?
— что-то непонятное произошло при чтении отпечатка?
— понедельник?

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

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

Еще один пример данных, на который я к сожалению пока и не нашел ответа:

В приложении мы показывает пользователям экран с предложением о покупке, где объясняем все преимущества платной версии. У пользователя есть возможность купить или пропустить. 90% пользователей, которые увидели этот экран, нажимают кнопку купить. После этого идет стандартный системный (google / apple) диалог о покупке.

Так вот покупают приложения только 0.1% из тех пользователей, кто нажал "купить" на предыдущем экране.

Какая еще аналитика полезна

Аналитика круто решает технические вопросы, а также вопросы качества и перформанса — не только продуктовые задачи.

Интеграционное тестирование

Проверяем похоже ли поведение пользователя на то, как мы его задизайнили.

При разработке нового функционала, мы проектируем его следующим образом: пользователь должен пройти определенный путь A → B → C → D.  Что происходит, когда мы видим, что пользователь делает A → C → E → D?

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

Анализ технических и нефункциональных данных. Производительность важных компонентов. Качественный анализ результатов.

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

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

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

• Время между нажатием кнопки «сделать фото» и моментом «открытия затвора», то есть моментом, когда камера реально начнет фотографировать
• Время обработки и сохранения изображений
• Анализ качества полученных фотографий
• Анализ параметров вспышки, с которыми делается большинство фотографий
• Анализ освещенности окружения

Примеры важных данных, которые мы умеем собирать, помощью вспышек:

• Как долго живет батарея?
• Как быстро перегревается устройство?
• Сколько вспышек может сделать ксеононовая трубка (xenon tube)?

Что мы делаем с этими данными?

Разберу 2 примера: первый сильно влияет на UX, второй на разработку новых устройств.

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

Может показаться «Ну сделал фотку и сделал, зачем нам знать сколько там времени прошло пока открывался затвор?»

Дело в том, что скорость, с которой пользователь может фотографировать, напрямую влияет на его ощущения удовлетворенности приложением. Круто если между нажатием кнопки и фотографией проходит 100мс. Но что если это 2-3 секунды? Пользователь может просто устать от ожидания фотографии.

Измерение этих данных и причин вызывающих задержку позволили нам осознать (и впоследствие сильно улучшить) то, что фокусировка камеры может занимать в не самом печальном случае — 1 секунду, а простое выставление white balance — около 200мс. Каждая операция увеличивает драгоценное время.

Анализ параметров вспышки с которыми делается большинство фотографий.

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

Допустим:

Мы задизайнили вспышку, которая умеет делать «импульсы» силой от 1 до 10 (условная величина) и длиной 0.5 - 100ms. При этом, с технической точки зрения, некоторые комбинации этих параметров (например: силу 1 на длине 100ms) очень сложно получить: чтобы эти параметры поддерживать нужно более дорогие компоненты.

Вы уже наверное догадались?

Если данные могут подтвердить, что пользователи в основном используют силу 3-9 на длинах Зms - 40ms, это существенно снизит требования к электронике при разработке новых продуктов.

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

Продвижение. Социалки.

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

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

О своих продуктах я стараюсь говорить как можно раньше, с целью:

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

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

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

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

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

• новым полезным знакомствам
• источникам идей и информации из других областей жизни

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

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

Подведём итоги:

Я уверен, что создание своих продуктов поможет вам осознать важность раннего продвижения, создания комьюнити вокруг продукта и активности в соц. сетях. Ведь когда-то вам так или иначе придется это сделать, так зачем ждать?

Privacy И legal

Использование чужого бренда

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

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

Дурацкая история произошла с моим приложением «менеджер паролей», тогда он назывался PassKeep — password manager.

Американская компания нажаловалась на меня в Apple, за то что я использовал фразу "password manager", которая является зарегистрированным ими трейдмарком в США. После этого было довольно долгое и неприятное разбирательство через Apple Customer Support. Приложение, которое в сторе уже много лет было на грани удаления из-за такой ерунды.

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

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

Картинки и музыка

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

Я бы посоветовал поступать так как будто собираете грибы. Если точно не уверены, что он съедобный... в смысле, если не уверены, что у ресурса нет правообладателя, то лучше его не используйте.

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

Third-party libraries

Возможно для кого-то то, что я скажу станет открытием, но многие open-source библиотеки имеют свою лицензию.

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

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

Делая свой продукт задумываешься о таких вещах самостоятельно, чтобы избежать возможных проблем в будущем. Благо есть очень простой и удобный ресурс для проверки лицензий — https://tldrlegal.com/.

Privacy

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

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

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

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

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

Открытие бизнеса

Создание своего продукта — уникальная возможность попробовать себя в роли основателя бизнеса. Вдруг это «ваше»? Мне лично очень нравится ощущение от работы в компании над продуктом, который несёт ценность и пользу, а если это еще и твой бизнес — идеальное комбо.

Нюансы ведения компании

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

Меня долго останавливала и пугала бюрократия необходимая для открытия компании. Живя в Беларуси я был вынужден открыть ИП, иначе не было вариантов как получать даже минимальные деньги с AppStore/GooglePlay. Удивительно, но ничего особо сложного в этом процессе нет.

В Швеции я открыл ИП в первый год после пеерезда. Кроме формального статуса ИП необходимого для получения дохода — это идеальный бюрократический инструмент для списания расходов. Даже с минимальной активностью по своим продуктам я трачу в год около 400-500$ на всякие сервисы типа: платного акка на гитхабе, пару доменов, пару серверов на Digital Ocean, Google Storage и т.п. Бонус в том, что я могу это списать, как расходы моего ИП и это будут деньги не облагаемые налогами.

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

Найм, увольнения.

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

Принимая людей на работу обычно думаешь над двумя вопросами: достаточно ли они хороши? Хотел ли бы я с ними сотрудничать?

А вот когда я ищу людей к себе в проект/продукт появляется второе измерение — деньги. Теперь это мои деньги, а не деньги компании. Начинаешь думать в таком ключе: достаточно ли они хороши, чтобы окупить «ценник», которые они ставят на свои услуги? Готов ли я вообще столько заплатить? Выгодно ли мне будет работать с этим человеком? Как тяжело будет уволить, если не сработаемся? Почему программисты хотят 300кк/сек?

Нанимать сложно, а увольнять еще сложнее. Чем-то напоминает процесс внедрения нового фреймворка, когда одним из главных вопросов становится «а если не пойдет, как будем вынедрять?»

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

Кто не смотрел, очень советую — доклад Виталия Шароватова на тему увольнений в IT. Доклад с конференции Podlodka TeamLead Crew в открытом доступе.

Зарплаты, налоги, расходы

Эта часть обозначу тезисно, т.к тянет на отдельную небольшую статью.

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

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

Меня очень улыбает тот факт, как некоторые компании (слышал такое про Российские) считают «общий бенефит» сотрудника. Берут его ЗП, добавляют туда «бонусы» в виде абонемента в качалку и еды в столовой и говорят: «ВОТ!»

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

Берем ЗП в 100$ + отчисления в пенсионный фонд 5$ + социальный налог на сотрудника 30$ и по итогу компания потратила 135$. А сотрудник получил на руки 70$, т.к отдал еще 30$ на налог штата (kommunalskatt).

Если добавить сюда "бенефиты" (я считал свои), то получается примерно 2.5% от всей суммы которую платит компания.

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

Думаю, понимание этих нюансов может:

1. помочь в переговорах о ЗП, если вы работаете как наемный сотрудник
2. помочь в оценке потенциальных расходов, если соберетесь создавать свой продукт

Научиться продавать: себя, свой проект, идею, работу

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

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

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

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

Обратите внимание на то, как люди в вашем окружении рассказывают на стендапах, что и как они сделали, как делаю демо или презентуют идеи. У моих коллег бывает, как то так:
Коллега рассказывает о своем прогрессе по проекту

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

Вывод:

Сегодня, именно человека знающего все это я бы назвал full-stack engineer или T-shaped (Ж-shaped).

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

Создавайте свои продукты, это увлекательно!