55 просмотров
19 мая, 2021
Относительно недавно у меня появилось новое полезное увлечение – я начал заниматься pet product. Не уверен, что каждый захочет с головой окунуться в это дело, но меня увлекло настолько, что почти все свое свободное время я посвящаю собственному pet project.
Сразу хочу сказать, что цель статьи – не продажа моих услуг или готовой разработки. Я даже не буду детально описывать инструмент для code review. Просто хочу рассказать, как и что я делал, чего достиг в результате. Уверен – среди читателей точно будут такие, которым мой опыт покажется не только интересным, но и полезным.
Относительно недавно у меня появилось новое полезное увлечение – я начал заниматься pet product. Не уверен, что каждый захочет с головой окунуться в это дело, но меня увлекло настолько, что почти все свое свободное время я посвящаю собственному pet project.
Сразу хочу сказать, что цель статьи – не продажа моих услуг или готовой разработки. Я даже не буду детально описывать инструмент для code review. Просто хочу рассказать, как и что я делал, чего достиг в результате. Уверен – среди читателей точно будут такие, которым мой опыт покажется не только интересным, но и полезным.
Если говорить о первом шаге, то я считаю, что им стало решение облегчить свою работу путем сокращения траты времени. К тому же хотелось сложную и рутинную работу сделать хоть чуточку более приятной. Но обо всем по порядку.
В течение последних восьми лет работы на ниве программирования я преимущественно изучал уже созданный код, но сам писал немного.
Даже с учетом того, что такой подход не является новым, именно он основной. Если говорить о сложностях, которые возникают, то они преимущественно связаны с отдельными алгоритмами. Проблема заключается в большом количестве компонентов и связей между ними – на определенном этапе работы уже становится невозможно их все помнить и учитывать.
Добавляет сложности и то, что необходимо тратить время и силы не только непосредственно на разработку новой функциональности, но и на component ownership. Полноценное владение кодом требует просто огромного объема работы:
Если попробовать весь обозначенный объем постоянной работы назвать одним словом, то это именно code review.
Лично у меня code review отнимал как минимум четверть всего рабочего времени. Доступный инструмент для выполнения этой нудной и неинтересной работы – git diff. Конечно же я в курсе, что существуют визуализации этого инструмента, и даже активно использовал SourceTree и GitHub pull requests. Но особо сути это не меняло, обязательными спутниками моего обычного рабочего дня были десятки вкладок в браузере, IDE с парой проектов, бесконечные полотна дифов… С учетом того, что я действительно люблю свою работу, вот эта вынужденная обыденность превращала ее в сущий кошмар.
Где-то подсознательно я понимал, что не одинок в этом ужасе, и что мои коллеги имеют аналогичные переживания. Но честно, мои размышления были достаточно эгоистичными – я хотел уменьшить и траты времени, и количество неприятных моментов в работе. И главное – я искренне верил, что другой сценарий возможен.
Искать сложный путь для решения сложной проблемы – это было бы слишком. Поэтому прежде всего я решил просто оптимизировать свою будничную работу. От полного понимания кода решить отказаться сразу же – это же непосильная задача. Вместо этого я взялся за формирование перечня простых задач, которые и формируют мой ежедневный рабочий процесс.
Если перейти на профессиональную терминологию, то речь идет о pull/merge requests и их code review. Большинство коллег не видят проблемы в этом отношении – все просто, быстро и без лишних трудностей.
А вот у меня тут совсем другое видение ситуации. Например, в системах, которые состоят из 70 деплоймент-юнитов и десятков тысяч строчек кода, не так и просто разбить новую фичу на фрагменты, подходящие для просмотра к выходу полного релиза. Поэтому даже элементарный просмотр изменений уже отнимает и силы, и время. Одновременно убивая вдохновение.
Еще один момент – бывали случаи, когда в нужный момент вносили изменения соседние команды. В такой ситуации не так-то просто найти, что именно было изменено, даже если речь идет о небольшом решении. И траты времени на это на самом деле колоссальные.
В процессе работы необходимо регулярно проверять и исправления, и новую фичу. В теории это просто, а на практике – тикеты не всегда имеют нужный объем данных. Поэтому поиск восстановленной галки в текстовом варианте тоже может стать интересным заданием, растянувшимся на часы.
А если внесенные изменения не имеют логической связи с фичей, то отыскать их будет еще сложнее. Подобное происходит и при внесении изменений в так называемое ядро системы. Или же когда компонент, которого коснулись непосредственные изменения, задействован в двух и более местах.
К тому же, не исключен и завал регрессии после изменений, и в первую очередь важно понять две вещи:
Ответить на эти вопросы смогут скорее сами разработчики, ведь они как никто другой знают все составляющие системы.
Главная задача программистов – это прямая реализация технического решения. Поэтому они нечасто зацикливаются на деталях и не учитывают, что релиз содержит в себе некое количество компонентов. Поэтому важно учитывать их последовательность и обновление конфигураций. А также важно спланировать, что обязательно необходимо включить в следующий релиз. Тогда же как release notes, собранные по тикетах в JIRA, не владеют данной информацией.
Поэтому каждый релиз, лично для меня, сопровождался исключительно выполнением diff между development и стабильной ветвью. То есть приходилось обрабатывать результаты за долгие недели или даже месяцы.
Все указанные действия являются повторяемыми и связанными между собой. И действительно отбирали кучу времени и сил. И именно поэтому я продолжил поиски путей решения проблемы.
Имея время и желание наконец найти решение своей проблемы, я пришел к первой гипотезе. В качестве цели я определил поиск системы, которая бы демонстрировала не строчное сравнение кода, а данные, которые касаются измененных компонентов.
Для себя я видел это приблизительно так:
Результат – две недели потрачено на создание презентации из 27 слайдов, которые наглядно демонстрировал гениальность моей идеи. Да, я был уверен, что она именно гениальная.
Среди моих знакомых есть люди, которые смогли объективно посмотреть на мою гипотезу и дать хороший совет. Поэтому я начал делиться идеей именно с ними. Восторга у них вызвать не получилось, скорее были нейтральные отзывы, которые не принесли мне никакого результата. Но проблема была скорее в том, что я сам не понимал, что хотел услышать.
Сдвинуться с «мертвой точки» помог один мой хороший товарищ, который имеет собственный опыт создания успешного продукта. Так вот, он порекомендовал мне отказаться от большей части моей «гениальной идеи» и оставить только одну функцию. И именно ее предложить реальным клиентам. Я прислушался к этому совету и, таким образом, из моих 27 слайдов осталось всего 2.
Другой знакомый посоветовал прочитать «Тест для мамы» Роба Фитцпатрика. И сейчас и считаю, что эти 140 страниц – лучшее, что мне удалось прочитать о разработке продуктов. Безгранично благодарен за эту рекомендацию и всем советую.
Далее последовала рекомендация ознакомиться с Startup School от Y Combinator. В последнем источнике я нашел для себя советы, которые помогли не только обучиться новому, но и существенно сэкономить время. Честно, я даже не верил, что получу именно такой глубокий результат.
Поскольку раньше моя деятельность была связана с участием в конференциях и пребыванием на так называемых python- и javascript-тусовках, я планировал продвигать идею именно среди участников этих мероприятий. Действительно, это была лучшая целевая аудитория. Но COVID-19 заставил меня изменить план действий. Но не сдаться.
Для поиска клиентов я выбрал LinkedIn. На тот момент для меня это был едва ли не единственный вариант. Потому что именно продавать я был еще не готов. Я даже не мог точно определить, чью проблему смог бы решить мой продукт. Не знал я и того, от кого ждать одобрения покупки. Все действия были достаточно хаотичными, построенными на собственных гипотезах.
Опираясь на собственный опыт, я решил, что моя идея не заинтересует программистов. А вот менеджерам точно понравится. Чтобы ускорить реализацию задумки, я активировал премиум-доступ и начались мои поиски ЦА в Sales Navigator.
Да, сейчас я уже точно могу сказать, что выбирая категории VP of Engineering, CTO или co-founder в компании до 50 людей, я ошибался. Но это сейчас, тогда я думал иначе и совсем не знал, как работает LinkedIn.
Немало вопросов возникало и на этапе обращения к потенциальному клиенту. Писать ему о своем гениальном продукте и обещать выгодное сотрудничество – конечно прекрасно. Но нужно в первую очередь понимать проблему человека, к которому обращаешься. Иначе получишь только игнор.
Ответы на самые животрепещущие вопросы я нашел в книге «Тест для мамы». Оттуда я узнал, как готовиться к интервью, и начал готовить сценарии будущих диалогов. Первым вопросом у меня всегда стояла возможность разговора на тему разработок в компании. Дальнейшие вопросы зависели от особенностей деятельности компании.
И даже такой подход не принес мне много откликов – около 5 реакций на 100 запросов.
Сейчас я точно знаю, почему случилось именно так, можно выделить три основные причины:
Мои догадки подтвердились, когда я изменил категорию на engineering, а потом на product manager. Программисты тоже не отреагировали. В целом, для себя убедился, что Linkedin – это раскрученный инструмент, но его эффективность ну очень завышена. Поэтому работу с ним я отложил до лучших времен.
Уверенно говорю, что данную учебную онлайн-программу считаю лучшей в своей сфере. И большинство людей, которые ее прошли, тоже считают, что лучше создавать стартапы не учат нигде. И это вполне логично, ведь ее автор – Y Combinator, то есть самый крутой акселератор стартапов.
Обучение по программе длится 8-10 недель:
Обучаясь в Startup School, я активно работал над идеей. Элементарное описание редактировалось несколько десятков раз. Я долго не мог понять свою основную проблему, но в процессе работы таки достиг цели. Все, что нужно, – научиться просто и доступно объяснять свою идею не только коллегам-программистам, но и людям, которые не имеют отношения к данной сфере.
То есть главная идея этой стартап-школы – научить людей объяснять свою идею максимально быстро и доступно для всех. На самом деле, это умение невероятно важное и будет нужным постоянно, пока вы будете заниматься продуктом.
Кроме того, эта школа — прекрасный вариант завести новые полезные знакомства. По крайней мере, у меня происходило именно так. Вскоре после окончания программы со мной связался бывший «однокурсник», который проявил интерес к моему проекту и поинтересовался прогрессом. Он был заинтересован делать бизнес вместе, поэтому познакомил меня с еще одним парнем, который мог создать успешный продукт. Не могу сказать, что эта цепь стала началом чего-то грандиозного, но для меня это были уверенные шаги вперед.
И пусть я еще не понимал, кто именно входит в состав моей целевой аудитории и как до них «достучаться», я уже сдвинулся с мертвой точки.
Основное преимущество этой школы стартапов в том, что видеолекции записывают специалисты, которые ведут основную программу акселератора. Это действительно невероятно полезно, я сейчас попробую вам это доказать.
Сначала я рассматривал акселератор стартапов как нечто совершенно иное, под углом собственных трат – $150k за 7% будущей компании. Но это вовсе не ошибочное направление мысли, потому что я получал значительно больше.
А именно:
Тут же мне предоставили доступ к потенциальным инвесторам.
Окончив зимний курс, я подал заявку на летний набор. Чуда не случилось, и я не прошел, но сама подготовка принесла позитивный результат – потому что я действительно готовился. Чего стоит одно записывание видео, в котором за 60 секунд нужно разрекламировать не только себя, но и продукт.
К тому же, в процессе создания рекламного ролика я смог сформулировать для себя важные вопросы, ответы на которые помогали в дальнейшей работе:
На самом деле, количество вопросов в моей голове было заметно большим. Я только поделился частью из них, выделив основные. И уже смотря с высоты своего собственного опыта, я могу посоветовать всем начинающим обязательно заполнить форму на подачу в Y Combinator – это действие точно поможет сделать шаг в правильном направлении.
Любая школа стартапов советует делать многоуровневый запуск. То есть не просто запускать работу проекта, но и информировать публику о своей работе. Реклама должна быть запущена как можно раньше и громче – это важная составляющая успеха.
Изначальная реклама происходит сама по себе – общаясь с друзьями и делясь своими успехами и неудачами, вы уже делаете свой продукт известным. Но этого мало. Для расширения круга популяризации я бы советовал принимать активное участие в различных стартап-тусовках. Мне советовали такие платформы, как Hacker News и Product Hunt. К сожалению, я вовремя не прислушался к этому очень мудрому мнению, так что не повторяйте мои ошибки.
И научитесь делать свои ожидания реальными – получить совет касаемо создания продукта вполне возможно. А вот формирование целевой аудитории и общение – этому можно научиться исключительно делая что-то для стартапов, например, Stripe или Unicorn Nest.
Еще одна моя ужасная ошибка – сделать рабочее решение, имея серьезные проблемы с привлечением целевой аудитории. В результате потратил огромное количество времени, а продвинуться вперед не удалось.
Сейчас расскажу, как формировалось решение писать код. Прежде всего я –программист, а стратап рассматривал как другое направление деятельности. Плюс добавилось и то, что я реально оценивал свои таланты в сфере менеджмента – откровенно посредственные. Поэтому написание кода было для меня так называемой проверкой на «профпригодность». Тут все оказалось в порядке – за время испытания себя в роли стартапера программировать я не разучился. Пригодился мой опыт длиною в 12 лет, который помогает работать уже почти на автомате.
Моей первой задумкой стало создание универсального алгоритма, который пригодился бы менеджерам. Но даже для себя я не мог сформулировать точные вопросы, на которые отвечал бы этот алгоритм. Для меня это было нечто среднее между информированием о добавлении новой клавиши на экран и предупреждении о новом public API или миграции в базе данных. Как видите, вопросы довольны абстрактные.
Но самое интересное началось, когда я начал визуализацию своего замысла – оказалось, что мои обещания из презентаций практически невозможно воплотить в жизнь. Причина заключалась в том, что самый простой алгоритм отображения архитектуры требовал такого количества времени, которого у меня не было.
На этом моменте я подумал, что можно перевести решение в open source. В этом случае определенный процент функционала оставался для моих перспективных проектов. Это позволило мне создать основную структуру, которая является универсальной платформой для любого веб-проекта. Далее же я начал работу над конкретной функциональностью продукта. Запуск вызывал определенные трудности на разных этапах – например, я уже упоминал, как разворачивать и поддерживать инфраструктуру. Но это точно было полезным для дальнейшей работы.
В процессе работы мне много что удивляло, потому что раньше я с этим просто не сталкивался и не понимал многих нюансов. То, что продукту просто необходима страничка, которая будет знакомить с ним, стало почти что шоковым открытием. Уверен, что большинство моих читателей тоже не делали самые простые сайты для своих продуктов. Но это неправильно – информационные странички должны быть.
Я начал работу над ошибками и достаточно быстро сверстал простую страничку. Это дало мне возможность понять, что и этого мало – ведь информации о готовом продукте будет значительно больше, чем можно разместить на новоиспеченном ресурсе. В качестве решения для информационного сайта я выбрал Hugo. В дальнейшем уже смог добавить несколько маркетинговых инструментов, среди которых самым важным считаю именно аналитику.
Советую всем, кто ведет работу по созданию нового продукта: уделяйте достаточно внимания информации для целевой аудитории, это точно облегчит всю дальнейшую работу. Не игнорируйте совет об использовании маркетинговых инструментов – с ними тестирование идей и поиск правильных решений будет более легким.
Если бы года эдак полтора назад кто-то дал мне подобные советы, я бы, наверное, смог избежать большого количества ошибок. Поэтому попробую помочь рекомендациями, которые основываются на моем личном опыте. Это буле полезно всем, кто уже начал или только планирует работать над собственным продуктом.
Попробую коротко подвести итог тому, о чем так долго рассказывал в этой статье. Главная причина остановки большинства стартапов – продукт не интересен для аудитории, потому что не решает ее проблему. А все потому что автор зациклился на решении собственной проблемы, часто – очень переоцененной. Поэтому сначала доступ к потенциальным клиентам и поиск путей увеличения их количества, а потом уже работа над продуктом.
На этом все, очень благодарен, что заинтересовались моей статьей. И буду невероятно рад, если смог быть полезным.
Python — именно этот язык для изучения предлагала мне таргетированная реклама лет эдак 5 назад. Я на тот момент была так же далека от IT, как и от рекламы, поэтому просто скролила непонятные картинки из другого мира. Не знаю, повлияли ли они на меня за столько лет, но в результате именно Python я выбрала в качестве первого языка программирования.
6 ноября, 2022
168 просмотров 
На то, чтобы найти “ту самую работу”, ушли недели. На то, чтобы составить правильное резюме, ушли часы.
Почти готово.
Финальный штрих — сопроводительное письмо.
26 мая, 2021
217 просмотров 
Если вам необходимо заказать проект у сторонних исполнителей, в котором отсутствуют жесткие требования к качеству, попробуйте поработать с подрядчиками по техническому заданию. Этот план поможет разработать веб-портал, красивый и удобный дизайн, создать статью для блога или услуги. Благодаря ТЗ вы сразу конкретизируете собственные пожелания и избежите “косяков”. Давайте более детально разберем, что из себя представляет этот план работ, какие есть тонкости нюансы его составления.
25 мая, 2021
129 просмотров 
Украинский рынок труда в сфере IT является кандидатским. Это означает, что специалисты получают работу по принципу “не меня выбирают, а я выбираю”. Это приводит к высокой конкуренции между компаниями за лучшие кадры.
И вот тут на арену выходит HR, который либо обеспечит компанию реальным специалистом, либо же выпустит его в пользу конкурента. К сожалению, второе происходит очень часто из-за обидных ошибок рекрутера.
19 мая, 2021
100 просмотров 
Добавить комментарий