Головна ---- Вибір напрямку ---- Моя історія створення продукту

Моя історія створення продукту

Відносно нещодавно у мене з’явилося нове корисне захоплення – я почав займатися 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 деплоймент-юнітів та десятків тисяч строк коду, не так і просто розбити нову фічу на фрагменти, що підходять для перегляду до виходу повного релізу. Тому навіть елементарний перегляд змін вже віднімає і сили, і час. Одночасно вбиваючи натхнення.  

Ще один момент – бували випадки, коли в потрібний компонент вносили зміни чотири сусідні команди. В такій ситуації не так то просто знайти, що саме було змінено, навіть якщо мова йде про невелике рішення. І витрати часу на це насправді колосальні.

Аналіз змін для QA

В процесі роботи необхідно регулярно перевіряти і виправлення, і нову фічу. В теорії це просто, а на практиці – тікети не завжди мають потрібний об’єм даних. Тому пошук встановленої галки в тестовому варіанті теж може стати цікавим заняттям на години.

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

До того ж, не виключений і завал регресії після змін, і в першу чергу важливо зрозуміти дві речі:

  • чи це було очікуване явище;
  • як запустити оновлення тесту.

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

Підтвердження релізу

Головна задача програмістів – це пряма реалізація технічного рішення. Тому вони нечасто зациклюються на деталях та не враховують, що реліз містить в собі певну кількість компонентів. Тому важливо враховувати їх послідовність і оновлення конфігурацій. А також важливо спланувати, що обов’язково потрібно включити до наступного релізу. Тоді ж як release notes, зібрані по тікетах в JIRA, не володіють даною інформацією.

Тому кожен реліз, особисто для мене, супроводжувався виконанням diff між development і стабільною гілкою. Тобто доводилося обробляти результати за довгі тижні, або й навіть місяці.

Всі вказані дії є повторюваними і пов’язаними між собою. І дійсно відбирали купу часу та сил. І саме тому я продовжив пошуки шляхів вирішення проблеми.

Рух в правильному напрямку

Маючи час та бажання знайти нарешті рішення своєї проблеми, я дійшов до першої гіпотези. За ціль я поставив пошук системи, яка б демонструвала не строкове порівняння коду, а дані, що стосуються змінених компонентів.

Для себе я бачив це приблизно так:

  1. Зараз я вважаю свої подальші дії помилковими, тоді ж вони мені здавалася єдино вірними.
  2. Я почав не шукати однодумців, а працювати над візуалізацією свого майбутнього рішення.

Результат – два тижні витрачено на створення презентації з 27 слайдів, які наглядно демонстрували геніальність моєї ідеї. Так, я був впевнений, що вона саме геніальна.

Рух в правильному напрямку

Маючи час та бажання знайти нарешті рішення своєї проблеми, я дійшов до першої гіпотези. За ціль я поставив пошук системи, яка б демонструвала не строкове порівняння коду, а дані, що стосуються змінених компонентів.

Для себе я бачив це приблизно так:

  1. Зараз я вважаю свої подальші дії помилковими, тоді ж вони мені здавалася єдино вірними.
  2. Я почав не шукати однодумців, а працювати над візуалізацією свого майбутнього рішення.                                                                                           

Результат – два тижні витрачено на створення презентації з 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 запитів.

Зараз я точно знаю, чому сталося саме так, можна виділити три основні причини:

  • люди рідко користуються LinkedIn і просто не читають подібні запити;
  • користувачам LinkedIn за тиждень приходить до 10 таких запитів, на які вони з часом просто перестають реагувати
  • звернення незнайомої людини про допомогу не викликає позитиву і бажання співпрацювати.                                                                                  

Мої здогадки підтвердилися, коли я змінив категорію на engineering, а потім на product manager. Програмісти теж не зреагували. В цілому, для себе я впевнився, що Linkedin – це розкручений інструмент, але його ефективність ну дуже завищена. Тому роботу з ним я відклав до кращих часів.

Startup School

Впевнено говорю, що дану навчальну онлайн-програму вважаю найкращою в своїй сфері. І більшість людей, що її пройшли, теж вважають, що краще створювати стартапи не навчають ніде. І це цілком логічно, бо її автор – Y Combinator, тобто найкрутіший акселератор стартапів.

Навчання за програмою продовжується 8-10 тижнів:

  1. Учні отримують цикл навчальних відео високої якості.
  2. Практична частина – це заплановані дзвінки, де кожен учасник представляє власний проект.
  3. Також є система трекінгу прогресу, яка виступає додатковим стимулом вивчати справу глибше і краще.                                                               

Навчаючись в Startup School, я активно працював над ідеєю. Елементарний опис редагувався кілька десятків разів. Я довго не міг зрозуміти свою основну проблему, але в процесі роботи таки досягнув мети. Все що треба – навчитися просто і доступно пояснювати свою ідею не тільки колегам-програмістам, але і людям, не маючим відношення до цієї сфери.

Тобто головна ідея цієї стартап-школи – навчити людей пояснювати свою ідею максимально швидко і доступно для всіх. Насправді, це вміння надзвичайно важливе і буде потрібно постійно, поки ви будете займатися продуктом.

Крім того, ця школа – прекрасний варіант завести нові корисні знайомства. Принаймні, у мене відбулося саме так. Невдовзі після закінчення програми зі мною зв’язався колишній «однокурсник», який проявив інтерес до мого проекту та поцікавився прогресом. Він був зацікавлений робити бізнес разом, тому познайомив мене з ще одним хлопцем, який зміг створити успішний продукт. Не можу сказати, що цей ланцюжок став початком чогось грандіозного, але для мене це були впевнені кроки вперед.

І хай я ще не розумів, хто саме входить до складу моєї цільової аудиторії та як до них «достукатися», я вже зрушив з мертвої точки.

Y Combinator

Основна перевага цієї школи стартапів в тому,  що відеолекції записують спеціалісти, які ведуть основну програму акселератора. Це дійсно неймовірно корисно, і зараз я спробую це довести всім.

Спочатку я розглядав акселератора стартапів дещо інакше, під кутом власних витрат – $150k за 7% майбутньої компанії. Але це геть помилковий напрямок думок, бо я отримував значно більше.

А саме:

  • знайомство з найбільш рейтинговими спеціалістами сфери стартапів;
  • взаємодія з ними на протязі 90 днів;
  • якісна підготовка власного продукту до презентації інвесторам.

Тут же мені надали доступ до потенційних інвесторів.

Закінчивши зимовий курс, я подав заявку на літній набір. Дива не сталося і я не пройшов, але сама підготовка принесла позитивний результат – бо я дійсно готувався. Чого вартий тільки запис відео, де всього за 60 секунд варто розрекламувати не тільки себе, але й продукт.

До того ж в процесі створення рекламного ролику я зміг сформулювати для себе важливі питання, відповіді на які допомагали в подальшій роботі:

  • Для чого я роблю цей продукт?
  • Чому саме я зможу зробити найкращий продукт?
  • Яким чином я планую отримувати прибуток?
  • Який об’єм доходу зможе принести саме цей продукт?
  • Як я буду шукати реальних покупців?                                                                                                                                                                                               

Насправді, кількість питань в моїй голові була значно більшою. Я лиш поділився частиною з них, виділивши головні. І вже дивлячись з висоти власного досвіду я можу порадити всім початківцям обов’язково заповнити форму на подання в Y Combinator – ця дія точно допоможе зробити крок у правильному напрямку.

Популярні стартап-тусовки

Будь-яка школа стартапів радить робити багаторівневий запуск. Тобто не просто запускати роботу продукту, але й інформувати публіку про свою роботу. Реклама має бути запущена якомога раніше і гучніше – це важлива складова успіху.

Найперша реклама відбувається сама собою – спілкуючись з друзями та ділячись своїми успіхами і невдачами, ви вже робите свій продукт відомим. Але цього мало. Для збільшення кола популяризації я би радив приймати активну участь в різноманітних стартап-тусовках.  Мені радили такі платформи, як Hacker News та Product Hunt. На жаль, я не вчасно прислухався до цієї дуже мудрої думки, тож не повторюйте моїх помилок.

І навчіться зробити свої очікування реальними – отримати пораду щодо створення продукту цілком можливо. А ось формування цільової аудиторії та спілкування – цьому можна навчитися виключно роблячи щось для стартапів, наприклад, Stripe чи Unicorn Nest.

Створення життєздатного продукту

Ще одна моя жахлива помилка – рішення зробити працююче рішення, маючи серйозні проблеми з залученням цільової аудиторії. В результаті витратив величезний об’єм часу, а просунутися вперед не вдалося.

Зараз розкажу, як формувалося моє рішення писати код. В першу чергу я – програміст, а стартап розглядав як інший напрямок діяльності. Плюс додалося й те, що я реально оцінював свої таланти в сфері менеджменту – відверто посередні. Тому написання коду було для мене так званою перевіркою на «профпридатність». Тут виявилося все добре – за час випробовування себе в якості стартапера я не забув, як програмувати. В нагоді став мій досвід довжиною в 12 років, який допомагає працювати вже майже на автоматі.

Моєю першою задумкою стало створення універсального алгоритму, який би став в нагоді менеджерам. Але навіть для себе я не міг сформулювати точні питання, на які б відповідав цей алгоритм. Для мене це було щось середнє між інформуванням про додавання нової клавіші на екран та попередження про новий public API або міграції у базі даних. Як бачите, питання доволі абстрактні.

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

На цьому моменті я подумав, що можна перевести рішення в open source. В цьому випадку певний відсоток функціоналу лишався для моїх перспективних проектів. Це дозволило мені створити основну структуру, яка являється універсальною платформою для будь-якого веб проекту. Далі ж я почав роботу над конкретною функціональністю продукту. Запуск викликав певні труднощі на різних етапах – наприклад, я вже згадував, як розгортати і підтримувати інфраструктуру. Але це точно було корисним для подальшої роботи.

Landing page

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

Я почав роботу над помилками і досить швидко зверстав просту сторінку. Це дало мені можливість зрозуміти, що й цього замало – бо інформації про готовий продукт буде значно більше, ніж можна розмістити на новоствореному ресурсі. Рішенням для інформаційного сайту я обрав Hugo. В подальшому уже зміг додати декілька маркетингових інструментів, найважливішим серед яких вважаю саме аналітику.

Раджу всім, хто веде роботу по створенню нового продукту – приділяйте достатньо уваги інформації для цільової аудиторії, це точно полегшить всю подальшу роботу. Не ігноруйте пораду про використання маркетингових інструментів – з ними тестування ідеї та пошук правильних рішень будуть значно легшими.

Підбиваємо підсумки

Якби років так півтора назад мені хтось дав подібні поради, я б, напевно,  зміг уникнути величезної кількості помилок. Тому спробую допомогти рекомендаціями, що гуртуються на моєму власному досвіді. Це буде корисно всім, хто вже розпочав або тільки планує роботу над власним продуктом.

  1. Встановлюйте міцні дружні стосунки всюди, де це можливо. Знайомі завжди більш уважні і доброзичливі – і це точно знадобиться, рано чи пізно.
  2. «Тест для мами» неодмінно треба прочитати. Просто зробіть це і зрозумієте, чому я так категорично це раджу.
  3. Створення презентації одразу після виникнення ідеї дорівнює марній втраті часу. Приділіть увагу пошуку проблем в задумі – це точно змусить міняти концепцію. І не один раз.
  4. Відмовившись від презентації, відмовтеся і від написання коду на моменті обробки власної ідеї. Це допоможе зекономити місяці власного часу, повірте мені. Бо не виключено, що ідея виявиться хибною.
  5. Спочатку пошук цільової аудиторії, а потім вже створення інформаційного ресурсу і простого MVP.
  6. Говоріть з друзями і знайомими про свою ідею. Тільки не чекайте схвалення, а думайте, яким чином зможете вирішити певні проблеми свого співрозмовника. Не виключено, що рішення доведеться кардинально змінити. Але якщо воно буде реально потрібним – то зусилля не марні.
  7. Маєте ідею і хочете її реалізувати? На цьому етапі участь в Startup School просто необхідна.
  8. Займіться заповненням заявки в Y Combinator. Парадоксально, але її можна навіть не відправляти. Просто вона допоможе зрозуміти, що робити далі.
  9. Самостійне написання статей дуже важливе – опановуйте це ремесло. Тут все просто – якщо зробите відомим себе, просувати продукт буде легше.
  10. Використання Grammarly коштує всього 130 доларів на рік. Це значно дешевше, ніж оплата праці людини, яка б зайнялася цим. І швидше. І просто необхідно при написанні статей англійською.
  11. Починайте запускати продукт там, де простіше масштабуватися. Звичайно, хочеться чогось глобального і митєвого підкорення ринку США. Але знайти аудиторію, наприклад, в Україні, буде простіше. Не звертайте увагу на конкретне місце – краще сконцентруватися на зацікавлених клієнтах. Таку стратегію успіху застосовують багато світових гігантів. Наприклад, AXDRAFT.                                                          

Спробую дуже коротко підсумувати все, що так довго розповідав в цій статті. Головна причина зупинки більшості стартапів – продукт не цікавий для аудиторії, бо не вирішує її проблеми. А все тому, що автор зациклився на вирішенні власної проблеми, часто – дуже переоціненої. Тому спочатку доступ до потенційних клієнтів і пошук шляхів збільшення їх кількості, а вже потім робота над продуктом.

На цьому все, надзвичайно вдячний, що зацікавилися моєю статтею. І буду просто неймовірно радий, якщо зміг бути корисним.

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

Читайте також
зайти в ІТ
Як виконати технічне завдання?

Якщо вам потрібно замовити проект у сторонніх виконавців, у якому відсутні жорсткі вимоги до якості, спробуйте попрацювати з підрядником за технічним завданням. Цей план допоможе розробити веб-портал, красивий і зручний дизайн, створити статтю для блогу або послугу. Завдяки ТЗ ви одразу конкретизуєте власні побажання та уникнете «косяків». Розберімо більш детально, що собою являє цей план робіт, які є тонкощі та нюанси його створення.

7 Травня, 2021
28 переглядів
життя компанії
Полюємо на кандидатів: куди краще не писати

Існують лише 10 % диваків, яким все одно — через «тєлєгу» їх найматимуть чи Linkedin. Решта, хто шукає роботу, думають інакше та віддають перевагу конкретним каналам зв’язку. Про це мають пам’ятати рекрутери, які хочуть швидко завершити процес найму, а не «піти далеко і надовго».

21 Квітня, 2021
100 переглядів
зайти в ІТ
Розробка комп’ютерних ігор

Більша частина поціновувачів рок-музики в якусь мить свого життя бере до рук гітару або сідає за барабанну стійку. Фанати футболу мріють вийти на поле та прокатити м’яча. Ті, хто обожнюють ганяти в GTA, досягли успіхів у популярних стратегіях або можуть годинами грати в Counter-Strike, точно бодай раз замислювалися над професією game-developer.

9 Квітня, 2021
36 переглядів
зайти в ІТ
Как выбрать язык программирования?

Раньше до того, как появилась глобальная паутина мобильные системы айтишнику было достаточно знать один язык, писать на нем код и он уже считался востребованным девелопером. Сегодня даже к junior-специалистам работодатели предъявляются большой перечень требований, среди них — знание не только одного языка программирования.  Сейчас web-разработчику нужно понимать, как работать ПХП, Джаваскрипт, Питоном, а еще неплохо […]

30 Березня, 2021
18 переглядів