Commited: 50+ воркшопів з ТОПами тестування: M.Bolton, G.Bahmutov, T.King, R.Desyatnikov, J.Bach. Лише за $40 на рік та економія $15 до 20 квітня
×Закрыть

«Більше не хочу працювати в аутсорсі — лише в продукті». Android-розробник — про своє бачення кар’єри та зафейлений стартап

Сьогодні розробник Ігор Янішевський живе з дружиною у Кельні. Працює в компанії Eyeo, що відома розробкою Adblock Plus. До цього п’ять років прожив у Братиславі, а починав кар’єру на заводі в Україні. Після кількох спроб працювати в аутсорсі, де відносини між замовником і виконавцем вважає токсичними, вирішив обрати тільки продукт. Створив стартап, яким разом з невеличкою командою займався два роки. Чимало часу приділяє менторству — викладав у кількох школах в Україні та за кордоном. Переконаний, що справжнє навчання має бути безкоштовним. Що вважати факапом, а що вдалим досвідом і про шлях Ігоря в професії — далі.

Старт у Кропивницькому

Я закінчив Кіровоградський національний технічний університет у 2009 році за спеціальністю «Системне програмування». На той час без «вишки» було важкувато, оскільки бракувало ресурсів для самоосвіти. Тоді були лише книжки, непросто було знайти ментора, дізнатися практичні кейси. На моїх перших місцях роботи університетські знання однозначно знадобилися, проте 5-річну програму можна було б втиснути в один рік навчання, бо викладали багато зайвого.

Ще на другому курсі почав підробляти. Влаштувався на пів ставки на позицію Embedded-розробника на завод Radiy в Кропивницькому.

Я працював з програмованою логічною матрицею Altera Cyclone. Дивлячись на це ретроспективно, розумію, що там не було організовано жодних процесів. Бос писав мені завдання в аську, потім підходив, і ми разом дивилися код. Пам’ятаю, що писали його на обрізаній C. Система контролю версій — це просто пересилання файлів одне одному. Тестувалося все уже в зборі на стендах, а насправді такий робочий процес був ще з 1990-х. Я виконував джуніорську роботу — діагностику. Це були студентські часи, платили мало — ставка орієнтовно 300 гривень за парт-тайм плюс 150 гривень премії на місяць.

Врешті мене переманили працювати системним адміністратором на інший завод — з виробництва олії. Два роки там треба було робити все, що казали. На заводі працювали 1500 людей, і майже всіх я знав на ім’я. Серед них були самодури, відверто некомпетентні працівники, були такі, що багато про себе думали, але на ділі мало що показували, а були й хороші спеціалісти. Ніби ціле окреме містечко.

Я виконував елементарну роботу: під’єднати мишку, зібрати комп’ютер, налаштувати мережу. Було багато завдань, які не мали нічого спільного з програмуванням. Атмосфера була спокійна. Іноді я спав у серверній, якщо напередодні щось «пересвяткував». Утім не можу сказати, що це була прогалина в кар’єрі: я вчився знаходити спільну мову з людьми, це була своєрідна школа життя. Ба більше, у той час питання кар’єри в галузі було невизначене. Це зараз айтішник — чувак з хорошою зарплатою, а тоді це були люди в страшних светрах і великих окулярах, які нікому не подобалися. Тому, коли я починав програмувати, це не було круто і впевненості в тому, що цим варто займатися, теж не було. Але мене цікавило ІТ ще зі школи, і я вирішив залишитися на цьому шляху.

Аутсорс: ніколи знову

У 2009 році у Кропивницькому з’явилися перші аутсорсингові компанії. Я пішов на співбесіду в найбільшу з них.

Показав їм свій проєктик: на заводі я розробив внутрішній телефонний довідник для працівників. Там була IP-телефонія (Asterisk). Довідник був простий: мав пошук абонентів, визначав завантаженість каналів пристроїв зв’язку, а також зеленим і червоним індикатором підсвічував тих абонентів, які були в мережі, і тих, хто поза зоною досяжності. Це був мій перший досвід на PHP.

Пам’ятаю, що мені ставили різні запитання в традиціях співбесід Google. Я не намагався віджартуватися, а хотів показати якусь логіку. Мене запитали, здається, про те, скільки хліба за місяць з’їдають жителі міста. Я сподіваюся, що нормально порахував. Фактично я пройшов співбесіду, маючи за плечима мінімальний досвід роботи на заводі й телефонний довідник. Також я гарно виконав тестове завдання, навіть перевиконав його, зробивши версію для тих, у кого був вимкнений JS. Мене взяли джуніором на позицію PHP-розробника. Спочатку я працював за 1,5 долара за годину.

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

Я не впевнений, чи можу розповідати в деталях, що саме ми розробляли. Це були різні плагіни для Xcard і WordPress. Компанія вимагала багато, але допомоги надавала мало. Був добре розвинений напрям iOS-розробки, але не було Android. Тоді ще тільки вийшла друга версія Android, я бачив у цьому перспективи, тому підійшов до свого менеджера з пропозицією: «Давай я повчуся програмувати на Android по вечорах у свій вільний час, і ми почнемо цей напрям у компанії». Він погодився, узгодив усе з керівництвом, знайшов кілька простих проєктів.

Так я став першим Android-розробником у компанії. Врешті мені дали велике завдання, і хоча ми естимейтили разом з менеджером, він виносив фінальний вердикт щодо дедлайну. І якщо такий самий проєкт на iOS робили командою 10 місяців, то мій на Android чомусь оцінили у три. Це був перший дзвіночок, що пора підшукувати нове місце роботи.

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

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

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

Продукт і ще раз продукт

У 2014 році я почав працювати в компанії Appsmakerstore на позиції Senior-розробника. Appsmakerstore — перший конструктор, де користувач може сам згенерувати застосунок з представлених блоків. Чи забирає це роботу в розробників? Я вважаю, що ні. У деяких людей, наприклад представників малого бізнесу, просто немає грошей, щоб замовити собі розробника. Тож вони або скористаються конструктором, або не матимуть своєї програми взагалі.

Були версії Appsmakerstore для iOS, Android і для вебу. Тут можна було створювати не лише застосунки, а й сайти. Я займався саме Android-напрямом. Ми створювали «шаблон» платформи для Android, який мав усі необхідні модулі та використовувався як база для генерації застосунку для клієнта (із зазначанням ідентифікатора, ресурсів і фінального APK).

Appsmakerstore через API вмикав і вимикав модулі, що було не дуже архітектурно красиво. Ми хотіли зробити так, щоб він генерував блоки динамічно, але не встигли це запустити, бо в засновника закінчилися гроші. У 2015 році він попросив мене працювати 20% часу, але й досі винен мені дві тисячі доларів. Це був складний період, бо ми саме переїхали з дружиною в Словаччину, тож я розумів, що треба швидко шукати роботу.

Переїзд був спонтанним рішенням. У Братиславі жили наші знайомі. Вони якось сказали, що є можливість піти на курси словацької мови й отримати посвідку на проживання. Ми порадилися і вирішили спробувати. Країна дуже маленька, затишна. Як на мене, головна різниця з тією ж Польщею полягає в тому, що в словаків немає упередженого ставлення до українців або ж вони його гарно приховують. Там є гарне українське ком’юніті, не заробітчан, а справді цікавих людей, зокрема тих, хто хоче відкрити стартап. У Словаччині приємні умови для бізнесу. Це, мабуть, стало основною причиною для переїзду.

Тоді ж у 2015 році я влаштувався розробником у невелику компанію Rocketshield, де з часом виріс до технічного ліда. Фактично це було двоє хлопців з Берліна, які вирішили поекспериментувати з блокувальниками реклами. Вони знайшли мене через референс. Я пройшов співбесіду, на якій ми просто спілкувалися про те, чим будемо займатися. Спочатку перевіряли концепт — для цього взяли Firefox і запхали туди розширення — блокувальник реклами, який уже був на ринку. Потім змінили браузер, на якому базується наш продукт, з Firefox на Chromium. Оскільки Chromium не підтримує екстеншени (розширення), довелося написати свій блокувальник нативно на С++, який підтримує формат фільтрів Adblock Plus.

Поступово вони взяли ще кількох людей у команду, переважно технічних інженерів. Робота там перевернула мою свідомість. Ніхто ніколи не тиснув на нас. Звичайно, запитували, скільки часу знадобиться на фічу. Ми працювали за канбаном, тому фічі оцінювали як розмір футболки S, M, L, XL, але ніхто ніколи не робив розбір польотів, чому це не було виконано вчасно. Могли спокійно обговорити, що сталося, якщо не встигали. В німців усе було добре сплановано, розписані всі процеси, а найголовніше — розробники завжди могли впливати на кінцевий продукт. Нас завжди запитували, як ми бачимо процес втілення ідеї. І ми як інженери відчували повну відповідальність за продукт, що це й наше дитя. Тож дуже раділи, коли було наступних 5 млн завантажень.

Я пропрацював там понад чотири роки, попросив 50% надбавки, а через два тижні після того, як мені її дали, звільнився. Річ у тім, що компанію продали. Її придбали не європейці, і ментально було важко звикнути до нових підходів. Усі наші поради повністю ігнорували. І не лише наші, а й колишніх фаундерів. Наприклад, коли виникла складна технічна проблема і єдиною опцією було найняти сторонній консалтинг, ми це запропонували. Натомість компанія намагалася розв’язати проблему внутрішніми ресурсами за допомогою іншого технічного відділу. Хоча всі знали, що хлопці не є експертами в Chromium. Ми витратили на це пів року й так і не вирішили проблему повністю. Звичайно, це було набагато дорожче, ніж залучити 20 годин консалтингу. А ще компанія стала великою, а тому більш бюрократизованою.

Зафейлений стартап

Усе почалося зі звичайного поста у фейсбуці. Один знайомий дизайнер написав, що пора брати ініціативу у свої руки й розробити щось самим. Так сформувалася команда з чотирьох людей: дизайнера, розробника (я), проджект-менеджера і маркетолога, який водночас був фронтменом. Останній ходив на зустрічі та конференції, де треба було представляти нашу компанію. Від початку в нас не було ідеї, а лише бажання зробити щось цікаве, мабуть, стартап.

Ми почали дивитися в бік застосунків батьківського контролю. Не всі зізнаються собі, що хочуть відпочити від дітей, і часом, коли ті підходять і просять телефон, дають їм його погратися. Ми подумали, що було б круто мотивувати дітей витратити цей час не просто на розваги, а й з користю. Більшість програм батьківського контролю мають заборонний характер — просто відімкнути чи заблокувати небажані застосунки. Ми ж, навпаки, створили застосунок FunControl, в якому діти за використання розвивальних і навчальних програм отримують монетки, які потім можуть витратити, щоб розважитися, — пограти в «погані» ігри. Таким чином ми хотіли збалансувати час, проведений за навчанням і розвагами. Ми намагалися оцінити ринок, провели багато інтерв’ю з майбутніми користувачами, був хороший фідбек.

Я одразу вирішив, що буде вигідніше найняти якогось розробника замість себе, тому що я не встигатиму працювати над застосунком вечорами після роботи. Я був би втомлений і витрачав би на це максимум кілька годин. Розробник же міг працювати фултайм. Тож я найняв у стартап девелопера, а сам зайняв позицію CТО. Робив рев’ю, за потреби допомагав йому, налаштовував СІ.

Мені навіть важко сказати, в чому була головна помилка. Мабуть, у тому, що ми не змогли швидко знайти гроші на продовження розробки. Ми спілкувалися з усіма ключовими компаніями в Братиславі, їздили на стартап-івенти, брали участь в місцевих акселераторах, та виявилися не досить досвідченими в пошуках інвестора. Ринок занадто маленький, поділений, хоча спершу здавалося, що він великий. Співвідношення величини ринку і технічної складності зіграло з нами злий жарт. Ми більше не змогли підтримувати цей застосунок. Складність полягала в тому, що він мав контролювати інші застосунки в телефоні, а це не так просто. Для цього ми використовували хаки, які на різних моделях телефонів працюють неоднаково добре. Особливо погано на Huawei.

Так, коли ми знайшли інвестора зі Словенії, який, як ми сподівалися, був готовий дати гроші, він запропонував для початку випробувати програму на щойно придбаному для доньки телефоні на Android (до цього в неї був айфон). Здогадайтеся, яку модель він придбав. Більше цього інвестора ми не бачили.

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

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

Команда кофаундерів Fun Control просить грошей в інвестора :)

Робота в компанії Eyeo в Кельні та найближчі плани

Коли я на початку 2020 року шукав роботу, то надіслав резюме лише в одну компанію — Eyeo. Здавалося, що зможу туди порівняно легко потрапити, а їхні проєкти мене цікавили. Eyeo — лідер в індустрії, їхній стандарт фільтрів Adblock Plus (а також і самі фільтри) використовують всі в галузі. Оскільки я до цього вже працював з блокувальниками реклами, то вирішив спробувати. Співбесіда не була дуже легкою, але мені не ставили дурнуватих питань а-ля Google і не казали писати на дошці код. Усе тому, що я вже попередньо виконав тестове завдання і вони бачили мій код.

Водночас було багато Computer Science, бо вони планували набрати людей, які працюватимуть з ядром адблокера. Мене поганяли по алгоритмах і Computer Science. Я трохи тупив, бо в щоденній роботі не думаєш про те, як працює HashMap, а тут доводилося згадувати. Потрібно було оцінити складність мого шматка коду. Це зараз багато де запитують, та я трохи гальмував. Однак пройшов інтерв’ю і далі займався блокувальником реклами, який був у певному сенсі конкурентом того продукту, з яким я працював на попередній роботі.

Головний офіс нашої компанії розташований у Кельні, є ще один в Берліні та в Мальме (Швеція). Так вийшло, що до цієї роботи я працював віддалено з 2011 року. Я дуже хотів піти нарешті в офіс — мріяв, що зустріну нових людей, питиму каву, їстиму фрукти. Та щойно влаштувався, гримнув ковід. Плакала моя офісна робота! Майже всі почали працювати з дому. Насправді компанія і далі платить оренду офісів, і якщо дома повний аут і діти сидять на голові, то можна виходити туди. Наша компанія не лише не постраждала фінансово, а й збільшила прибутки. Кількість користувачів зросла зі 40 млн до 160.

В Eyeo застосовуються принципи Servant leadership, коли головне завдання лідера — служити. Бос повинен створити якнайкращі умови для виконання працівниками задач. Крім цього, завдання нам не спускають згори. Ми вигадуємо їх самі. На регулярних зустрічах компанія розповідає, куди рухається і чого хоче досягти, а ми вже самі пишемо собі тікети, як цього технічно досягти. Раніше тут працювало лише 40 людей і зв’язки були, по суті, горизонтальні. Тепер, коли компанія зросла, уже є певна ієрархія.

Компанія поділяється на підрозділи — юніти, кожен з яких має певну ціль. Юніт же складається з бізнес-частини та інженерної частини. Технічний лід в юніті займається переважно адміністративною роботою, бо є чимало стратегій, зустрічей, планувань. Є ще Engineering Lead, в інших компаніях це Line Manager. Він займається кар’єрою спеціаліста, допомагає, якщо треба навчання, погоджує бюджет, оцінює ефективність працівника в кінці півріччя. Але це не бос, він не має права вказувати, що і як робити, окрім порад щодо кар’єри.

Мене влаштовує робота в Eyeo, але я хотів би створити ще кілька стартапів. Найближчим часом плануємо невеличкий проєкт — застосунок «Гороскоп». Це важко назвати стартапом, але наша мета — щоб ті, хто вірять у гороскопи, теж могли отримувати поради для саморозвитку і відчували, що вони можуть впливати на свою долю. Є ще кілька ідей, але я не впевнений, що вдасться повністю піти з розробки. Я не проти залишитися в технічній сфері, але на позиції розробника вже починаю вигорати. Проте хотілося б трохи зрости кар’єрно, бо є відчуття, що, якщо не можеш вирости у своїй компанії, то не зможеш і в стартапі. Ліди в Eyeo — це технічна стеля кар’єри. Річ у тім, що офіційно в компанії немає позиції Senior Developer. Всі оформлені як Software Engineer, але можна стати сеньйором неофіційно. Оскільки те, наскільки фахівця поважають колеги, враховують у його щорічній оцінці й це впливає на оплату.

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

Менторство

Я не задумувався про те, щоб почати читати курси спеціально. Якось їхав у маршрутці в Кропивницькому і побачив з вікна рекламу «Школа програмування. Набираємо студентів». Зайшов до них на сайт, побачив, що вони шукають менторів, і подумав, що було б круто ним стати. Написав листа, що готовий стати Аndroid-ментором за умови, що це буде безкоштовно для студентів.

Виявилося, що засновник школи Роман Шмельов — великий альтруїст і за свої зароблені гроші купував комп’ютери та платив оренду. Він не «витягував» повністю, тому спочатку навчання було платним, але це не було дорого. Зараз вони добре розвинулися: винайняли більше приміщення, застосовують метод «рівний рівному», коли вся відповідальність лежить на студенті. Немає викладачів, є лише записані наперед лекції та самоорганізованість. Як я знаю, нині використовують курс Stanford CS106a/b. Курси повністю безкоштовні. Є групи для молодшого шкільного віку, підлітків і дорослих.

Я мав ще один досвід менторства у компанії Brain Basket у Словаччині. У Братиславі я часто ходив у коворкінг Campus. І був у хороших стосунках з його фаундерами, а потім познайомив їх з Володею Люлькою, СЕО Brain Basket. Вони домовилися про приміщення та інформаційну підтримку, медіа, але чомусь нам не вдалося набрати достатню кількість людей для навчання. Я думаю, що це було частково пов’язано з тим, що там немає такої великої різниці зарплат, як в Україні. Немає прірви: IT трохи більше оплачується, ніж інші інженерні спеціальності, але не в рази. Запуск був невдалий. Було важко зібрати групу навіть з 5 осіб, хоча навчання було безкоштовне. Разом з колишнім СМО стартапу FunControl я випустив дві групи. Менторів знайшли багато, а охочих навчатися мало. Здається, врешті лише один з випускників моєї групи пішов працювати в IT.

Ігор на конференції в Кропивницькому

Поради і лайфхаки з працевлаштування та кар’єри

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

Я обираю роботу, пов’язану з технічною частиною, тому готовий працювати розробником або тімлідом, але не проджект-менеджером, бо це суто адміністративна посада, більш пов’язана із взаємодією з людьми. Якщо це стартап, то він має бути цікавим і перспективним. До великої компанії треба бути більш прискіпливим. Насамперед важливо проаналізувати вакансії, які вона постить. З цього видно сталення до співробітників. Якщо це довгий перелік обов’язків і вимог без гарантій з її боку, то не варто на позицію відгукуватися. Виняток: якщо компанія маленька і вакансію пише фаундер з розробником. Тоді інформацію можна уточнити безпосередньо в засновника. Нормальна вакансія містить інформацію про компанію, те, чим будете займатися (скіли мають бути співвідносні з безпосередніми завданнями, а не довжелезний перелік усіх можливих) і, звичайно, «плюшки». Інакше ризикуєте не отримати навіть стіл зі стільцем :)

Як підготуватися до співбесіди на позицію Аndroid-розробника? Універсальна порада вчити Computer Science не завжди працює, бо вам можуть взагалі жодного питання з цього не поставити. Перед інтерв’ю варто піти на ютуб-канал Android Developes і вибірково подивитися останніх 10 відео. Не всі підряд, а ті, що вас зацікавлять, щоб зрозуміти, чим дихає індустрія. Ну й докласти зусиль, щоб добре виконати тестове. Повторіть Java і Kotlin, патерни, також рекомендую прочитати книгу про антипатерни «Горький вкус Java». Можуть запитати і про Java Native Interface (згадайте, як викликати нейтів код). Повторіть основи з Android (Activity Lifecycle, компоненти Activity, Service, Content, Provider, BroadcastReceiver, Foreground Services, типи Permissions, віртуальні машини і Static Context).

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

Щодо зарплатні, то раджу використовувати таку схему: заходите для українського ринку на DOU, а для іноземного на Glassdoor, берете середню ринкову оплату і накидаєте зверху 10–30%. Далі дивитеся на реакцію, якщо HR говорить, що в них уже черга працювати за безцінь, накиваєте п’ятами, якщо ні — торгуйтеся і погоджуйтеся на той варіант, який вас влаштує. Якщо це компанія вашої мрії і ви розумієте, що дуже занизили собі ціну, то поцікавтеся переглядом зарплат у компанії, цілком можливо, що вдасться виправити ситуацію після випробувального терміну.

Я маю досить контроверсійну думку про навчання — воно мусить бути безкоштовним. Переконаний, що лише найкращі фахівці готові задарма витрачати вільний час. Хочу розвінчати міф «що дорожчі курси, то вони кращі». Як приклад, рекомендую школу Ш++ у Кропивницькому. Слухаю подкасти Android Developers Backstage, наша біблія — це developer.android.com. Добре працює нетворк, але навіть якщо ви суперсором’язлива людина, але маєте гарний відгук на Stack Overflow чи цікавий проєкт на GitHub, вас точно покличуть на роботу.

👍НравитсяПонравилось14
В избранноеВ избранном7
Подписаться на тему «работа»
LinkedIn

Похожие статьи




Підписуйтесь: iTunes | Google Podcast | YouTube


33 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

А для Interview — Done! Игорь рассказал о подготовке к прохождению собеседований для разработчиков приложений на Android OS. Ссылка на видео — www.youtube.com/...​0D1nV-go&feature=youtu.be
Спасибо, Игорь!

FPGA => ... => PHP

Це тільки підкреслює те, що люди різні. До кольору, до вибору...

Але я також не хочу працювати в аутсорсі. І вже не працюю. Хоч тут зійшлися.

Тоді були трохи інші часи. І PHP цінився вище за FPGA

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

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

Ну как тут не процитировать ДМБ:

«Молод ты ещё! Это не ты выбираешь присягу кастомера, это присяга кастомер выбирает тебя» ©

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

Ага, 10+ проектов и нигде не было токсичных кастомеров, я прям супер везучая)

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

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

Дякую за гарну позитивну цікаву історію

Сначала аутсорсишь на стартап
Потом стартапишь
Потом ищешь аутсорс для стартапа

Неа. Мы нанимали девелопера, и сейчас с новым проектом я делаю точно также. Никаких аутсорсов, ТЗ и контрактов

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

приятно видеть статьи со знакомыми лицами :)

ЦІкава стаття.
Дякую за україномовну статтю.

Никогда не понимал, если честно, этого карго-культа продуктовой разработки. Из того, что у меня было, например, процесс был ± один и тот же. Такой же был баланс между качеством/скоростью разработки, люди те же, процессы те же.

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

Ну тогда не просто «продукт», а только «B2C продукт»

Ну ок, а если в оутсорсе делается продукт? Если это стартап в оутсорсе?
Какая тогда разница?

А если сам не пользуешься то всё типа нещитово?
В отличии от массы коробочных продуктов(игр например) кровавый энтерпрайз наоборот имеет века «развития» (хотя наблюдать это далеко не всегда приятно бггг).
В общем случае основное отличие проходит исключительно в голове ИМХО.

Если это продукт Б2Б, то он тоже используется внутри какой-то компании.

А если продукт не нравится, но деньги платят?

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

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

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

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

Сложно иметь мнение, которое является абсолютно объективным. Мое мнение сложилось из моего опыта и опыта моих коллег.
Добавлю, что немного лучше все на аутстафе.

Тут в принципе важно то, какая суть отношений между заказчиком и исполнителем. Если это продуктовая компания, но существует процесс «приемки» и жёсткие сроки, то это не менее стрессово и напряжно.

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

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

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

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

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

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

Из позитивного: заказчики умнеют, учатся и держат аутсорсеров на микроконтроле, поэтому вышеозначенные показатели поддерживаются на приемлемом уровне, но только в первое время. Потом аутсорсер все больше перетягивает одеяло на себя, а заказчик из-за sunk cost fallacy уже на крючке и ничего не может глобально изменить.

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

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

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

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

Скорость разработки: настолько медленно, насколько это возможно, чтобы «забиллить» максимум часов, но достаточно быстро, чтобы заказчик не ушел к конкуренту.

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

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

Документация: настолько скудная, насколько это возможно

И тут тоже — после пары напоминаний стали поддерживать внутреннюю доку даже лучше чем мои орлы.

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

иначе — взуют. и хорошо если не по злому умыслу. а могут и по злому.

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

Иногда поражаешься, как заказчик просирает деньги и время...

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

правда жизни в том что на доу, как и на любом другом программерском форуме основаня масса коллег именно такая — очень далекая в цепочке от принимающих решения

и — сработались

В вашем примере ребята из аутсорса постепенно превратились в аутстафф :)

Согласен :)

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

Аджайл — это когда ОБЕ стороны по нем работают
В аджайл невозможно играть в одиночку.

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

но скажи это какому скрам мастеру, чего только не услышишь в ответ. самое мягкое это об эффекте Д-К

Скорость разработки: настолько медленно, насколько это возможно, чтобы «забиллить» максимум часов, но достаточно быстро, чтобы заказчик не ушел к конкуренту.

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

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

Подписаться на комментарии