47 переглядів
4 Лютого, 2021
Відносно нещодавно у мене з’явилося нове корисне захоплення – я почав займатися 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 слайдів, які наглядно демонстрували геніальність моєї ідеї. Так, я був впевнений, що вона саме геніальна.
Серед моїх знайомих є люди, які змогли об’єктивно подивитися на мою гіпотезу та дати слушну пораду. Тому я почав ділитися ідеєю саме з ними. Захвату у них викликати не вийшло, скоріше були нейтральні відгуки, які не принесли мені ніякого результату. Але проблема була більше в тому, що я сам не розумів, що саме хотів почути.
Зрушити з «мертвої точки» допоміг один мій хороший товариш, який має власний досвід створення успішного продукту. Так ось, він порекомендував мені відмовитися від більшої частини моєї «геніальної ідеї» і лишити тільки одну функцію. І саме її запропонувати реальним клієнтам. Я прислухався до цієї поради і таким чином з моїх 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. В подальшому уже зміг додати декілька маркетингових інструментів, найважливішим серед яких вважаю саме аналітику.
Раджу всім, хто веде роботу по створенню нового продукту – приділяйте достатньо уваги інформації для цільової аудиторії, це точно полегшить всю подальшу роботу. Не ігноруйте пораду про використання маркетингових інструментів – з ними тестування ідеї та пошук правильних рішень будуть значно легшими.
Якби років так півтора назад мені хтось дав подібні поради, я б, напевно, зміг уникнути величезної кількості помилок. Тому спробую допомогти рекомендаціями, що гуртуються на моєму власному досвіді. Це буде корисно всім, хто вже розпочав або тільки планує роботу над власним продуктом.
Спробую дуже коротко підсумувати все, що так довго розповідав в цій статті. Головна причина зупинки більшості стартапів – продукт не цікавий для аудиторії, бо не вирішує її проблеми. А все тому, що автор зациклився на вирішенні власної проблеми, часто – дуже переоціненої. Тому спочатку доступ до потенційних клієнтів і пошук шляхів збільшення їх кількості, а вже потім робота над продуктом.
На цьому все, надзвичайно вдячний, що зацікавилися моєю статтею. І буду просто неймовірно радий, якщо зміг бути корисним.
До команди ІТ-компанії входить багато різних спеціалістів. Від розробників і дизайнерів до менеджерів, маркетологів та рекрутерів. Найчастіше між ІТ-компанією як замовником та спеціалістом як виконавцем укладається господарський договір про надання послуг (Services Agreement). Поговоримо про його універсальні положення, на які слід звернути увагу, а також про специфіку контрактів з окремими спеціалістам
26 Липня, 2021
341 переглядів 
Python — саме цю мову для вивчення пропонувала мені таргетована реклама років 5 тому. Я на той момент була так само далека від IT, як і від реклами, тому просто скролила незрозумілі картинки з іншого світу. Не знаю, чи вплинули вони на мене за стільки років, але в результаті саме Python я обрала в якості першої мови програмування.
15 Липня, 2021
389 переглядів 
Нас часто запитують, чи беремо ми junior-фахівців в команду, якими знаннями потрібно для цього володіти, як проходить відбір та багато іншого.
27 Травня, 2021
305 переглядів 
Оцінка працівників — обов’язкова частина робочого процесу. Це важлива процедура, що дозволяє покращити діяльність працівників, дати їм зворотній зв’язок та забезпечити ґрунт для кар’єрного росту. Так людина може краще розуміти цінність своєї роботи, а компанія — бачити вклад кожного співробітника у спільну справу.
У кожної компанії свої методи оцінки. Підсумувавши всі, ми би хотіли виокремити 4 найбільш популярних способи оцінити продуктивність працівників у сфері ІТ.
Поїхали!
25 Травня, 2021
41 переглядів 
Залишити відповідь