Чому сервісна компанія — найкраще робоче середовище для більшості інженерів. Руйнуємо міфи про «галери»

Привіт! Мене звати Юрій Рощенко, я відповідаю за Delivery у сервісній компанії Proxet. Дехто скаже, аутсорс — галера, на якій розробникам нудно веслувати, де від кінцевого продукту інженера відділяє нездоланна дистанція, роками одне й те саме.

А я стверджую, що це абсолютно не так, і саме сервісна компанія — найкраще робоче середовище для більшості інженерів.

За понад 20 років роботи саме у сервісних компаніях я отримав різноманітний і багатогранний досвід — наче прожив декілька різних життів і перевтілювався у різні ролі та на різних проєктах. Тому із задоволенням виступлю руйнівником міфів та стереотипів про сервісні компанії.

Иллюстрация Марии Рыбак

Наша робота — програмування, наш результат — код. Міф перший

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

За моїми спостереженнями кодування становить не більше як 2/3 роботи Software-інженера. Окрім кодування, треба ще читати й розуміти контекст, вимоги, ставити правильні питання, пропонувати та обговорювати варіанти, інтегрувати свою роботу з роботою інших людей. Проєктування, планування, ознайомлення з готовими рішеннями, врешті-решт R&D і прототипи. А ще документація, тести, зустрічі, демо, естимейти...

Якщо у вас не так, навряд чи вас можна назвати кваліфікованим інженером з погляду сучасної дисципліни промислової розробки. Або ви просто кодер і вас з часом замінять No Code/Low Code системи, або вам байдуже і ви втрачаєте можливості впливати на продукт, або ви просто лінивець і не бажаєте розвиватися.

Weeks of coding save you hours of planning.
Jason Statham, probably

Гребці на галері. Міф другий

Часто сервісну компанію, або аутсорс, уявляють у вигляді галери, на якій поволі веслують гребці, роками прикуті кайданами до одних і тих самих проєктів.

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

Уявіть собі: компанія з США відкриває представництво, у якому 7 співробітників. Це нонсенс, бо з’явиться занадто багато специфіки та різних додаткових витрат. Набагато простіше звернутися до сервісної компанії й облаштувати команду того ж самого розміру. На стороні замовника буде працювати вся адмін-команда, досвід і репутація сервісного партнера.

Для ілюстрації наведу кілька наших проєктів.

  • Компанія, яка розробляє одну з найбільших торговельних онлайн-платформ у світі. Це американський єдиноріг у галузі електронної комерції. Компанія купує різноманітні інтернет-магазини, інвестує в них гроші та розвиває. Тут є Java, Python, RoR, Airflow.
  • E-commerce компанія — розробник системи телеветеринарії для однієї з найбільших у своїй галузі компаній в США. З початком локдауну власникам тварин стало складніше відвідувати ветеринарні клініки, і наш клієнт вирішив перенести послуги в онлайн — тепер огляд доступний по відеозв’язку. Команда проєкту використовує Java, Node.js, Vue.js, React, платформу OpenVidu.
  • Всесвітньо відомий бренд, розробник хостингу анімованих GIF-файлів і системи пошуку та індексації цих зображень за ключовими словами. Для забезпечення більш точного пошуку застосували Machine Learning, а також Python та Scala.

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

Сервісна компанія як «готель» завжди зацікавлена в тому, щоб надати найякісніший сервіс клієнтам. Останній неможливий без задоволених, розумних, сповнених енергії та ідей працівників, яким цікаво розвиватися у своїх напрямах. Намагатися «прикути» їх кайданами — це зрештою не в інтересах сервісної компанії, а запропонувати project change і провести ротацію — навпаки, реальна можливість. І у нас таких прикладів вистачає.

Один з наших інженерів працював у невеликому стартапі на Java-стеку. Повідомивши компанію, що хоче змінити стек, за декілька місяців перейшов на Python і в ньому теж досяг рівня Senior. Також розробники в нас часто переходять в Data-інжиніринг — це допомагає набагато глибше осягнути бізнес через процеси, стикаючись безпосередньо з його даними.

Треба веслувати, не можна керувати. Міф третій

Основна бізнес-модель сервісних компаній — співпраця з клієнтами. Отже, розвивати можна лише клієнтський продукт, а розробляти власний — прерогатива продуктових компаній.

Цей міф неодноразово руйнували самі розробники, щойно у них з’являлися ідеї та бажання щось зробити.

Якщо розробляємо продукти для інших компаній, чому б нам не спробувати створити його для себе? Адже в нас є бачення ринку, його потреб. Такий підхід повністю відповідає американському вислову «Eating your own dog food» — тобто користуйся власним продуктом чи сервісом.

Так сталося і з нами: ми розвиваємо свої продукти MatchMaster та MatchScout на базі власного рішення Employa. Платформа допомагає спростити етапи рекрутингу завдяки технологіям AI/ML. Система створена для пошуку та збору резюме релевантних кандидатів і дозволяє автоматизувати багато рутинних процесів, а отже зекономити кошти та зусилля. Ми самі користуємося власною системою, а також проводимо пілоти з клієнтами.

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

Дистанція між продуктом і розробником. Міф четвертий

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

Відстань від продукту до технічного виконання в сервісній компанії і справді може бути більша. Щоб наблизити себе до розуміння продукту і бізнесу, всього лише треба: а) захотіти, б) докласти трохи зусиль, щоправда, часто поза межами своїх звичних обов’язків.

Бракує розуміння продукту? Запитай!

Незрозумілі бачення і пріоритети? Запитай!

Не відповідають — нагадай, пропонуй варіанти, ініціюй дискусію. Головне — продуктивну. Ваші колеги теж зайняті люди.

Брак будь-якої інформації можна (і треба!) компенсувати активною комунікацією. І в цьому велика можливість для розвитку і вдосконалення.

Гнучкі методології та робота в невеликих командах сприяють покращенню ситуації.

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

Кривавий ентерпрайз. Міф п’ятий

Говоримо «сервісна компанія», маємо на увазі різноманіття клієнтів, в тому числі ентерпрайз. Словосполучення «кривавий ентерпрайз» декому знайоме і може лякати: монструозний проєкт, легасі-код, бюрократизовані процеси, жодного натяку на швидкість ухвалення рішень — певно, найяскравіші недоліки роботи з ентерпрайзом. Це все може сильно виснажувати.

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

Уявімо ситуацію: щось виходить з ладу на продакшені healthcare-платформи. Це торкнеться тисяч пацієнтів, дехто опиниться в черзі, а хтось вчасно не отримає медичної допомоги.

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

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


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

👍НравитсяПонравилось10
В избранноеВ избранном3
LinkedIn

Лучшие комментарии пропустить

В сервісних компаніях дійсно є позитивні моменти, але це не зовсім те, про що ви пишете.
Спробую перерахувати з точки зору рядового українського розробника:
1. Можливість роботи над продуктами і проектами із ЄС, США та іншого світу, які б розробник без аутсорс контори ніколи б не отримав.
2. Відповідно, витікаючи з першого пункту, зарплата — грошовитий проект в аутсорсі може платити багато, особливо багато якщо розробник компетентний, а на проекті горить.
Продукти часто не готові стільки платити, як аутсорс в якого горить.
3. Можливість найматися і звільнятися швидко. Набрид проект? Вигорів? Отримав офер на +500? Два тижні нотісу і тримайтесь, здоров’я вам, всього найкращого.
Звісно, для збереження хороших відносин і «обличчя», так робить рідко хто, але можливість є, а це головне.
4. Можливість отримання оферу за декілька днів. В аутсорсі часто все просто: Тебе знайшла ейчар, провела скринінг, технічна співбесіда, опціонально розмова з клієнтом чи менеджером — офер. При бажанні, це можна впихнути у 2-3 дні. Продукти ж їх багатораундовими інтерв’ю, cultural fit та тижнями роздумів втрачають багато кандидатів.
Не буду стверджувати, що це добре для компанії, не проводити повноцінного адекватного відбору, але якщо робота треба швидко — можеш отримати швидко.
5. Можна досить швидко рости по кар’єрній драбині. Якщо є бажання і ти себе добре проявляєш, нічого не завадить за рік-два вирости з джуна в мідли, за два-три з мідла в сіньйора, потім в ліди, архітектори і т.д.
Аутсорсери з постійно ростущими проектами потребують багато нової крові і у вчорашнього розробника багато можливостей стати завтрашнім лідом чи менеджером. Головне, мати ціль і працювати над нею, а також декларувати свої наміри менеджменту.
Ви можете бути не найкращим перформером або не найприємнішим у колективі, але коли контора потребуватиме нового ліда чи менеджера, з великою ймовірністю візьмуть того, хто сам проявлятиме ініціативу до цього.
6. Можливість посидіти на бенчі отримуючи зарплату і в принципі нічого не роблячи.
Мабуть, можна придумати ще якісь плюси.

Варто сказати, що ІТ індустрію України з тим всім, що є, сформували аутсорсери, за що я їм вдячний.

Запускайте програми опціонів та 4 денний робочий тиждень і тоді в аутсорсерів буде ще більше переваг)
Я вже тут писав, що перший великий аутсорсер який зробить 4-денний робочий тиждень, зніме всі вершки з ринку кандидатів.

Очень часто один из серьезных минусов продуктовой компании, как для разработчика — внезапно, сам продукт. И чем этот продукт дольше на рынке и успешнее — тем хуже, вот такой вот парадокс. Потому что принцип «работает — не трогай» никто не отменял, так что добро пожаловать в волшебный мир древних версий языков и фреймворков.
Ещё хуже, если продукт активно использует внутренние in-house фреймворки и/или DSL — скиллы которые приходится развивать и которые абсолютно не востребованы на рынке.

Чому сервісна компанія — найкраще робоче середовище

очевидно тому що ви

відповідаю за Delivery у сервісній компанії Proxet

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

Все інше то раціоналізація цього простого факту.
Успіхів вам і далі з перепродажом лавок та весел західним партнерам.

Бракує розуміння продукту? Запитай!

ain’t your business

Незрозумілі бачення і пріоритети? Запитай!

ain’t your business

Does anyone have any questions? No?

Row, row, row your boat
Gently down the stream
Merrily, merrily, merrily, merrily
Life is but a dream

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Когда слышу delivery manager, всегда представляется акушерка.

Или начальник доставщиков пиццы

Прочитав донощіков піцци

Мгм. Ні дня в продуктовій компанії і переконує, що галєра це дуже круто...

Помітив що люди з продуктів пишуть коментарі в основному анонімно або не пишуть взагалі. Вас дійсно б’ють за власну думку про компанію?

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

Често говоря статью лучше было бы назвать «Мифы про прекрасную не-галеру Proxet»!

За моїми спостереженнями кодування становить не більше як 2/3 роботи Software-інженера.

По моему опыту и того меньше! Новый код пишу максимум 30% времени. Все остальное — это попытки зарепродюсить баги и найти причину. А еще билды по пол-часа и развертывание по часу. Помимо кодирования — попытки получить ответы на вопросы от автора бага или задачи что же он имелл ввиду.

Набагато простіше звернутися до сервісної компанії й облаштувати команду того ж самого розміру.

Только вот нанимают они не специалистов (свои есть) — а чернорабочих! И сервисная ИТ компания (галера) — это как клининг компания, которая предоставляет уборщиц, а не какой-нибудь НИИ где разрабатывают проекты.

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

При этом:

Намагатися «прикути» їх кайданами — це зрештою не в інтересах сервісної компанії, а запропонувати project change і провести ротацію — навпаки, реальна можливість.

Или кто-то на галере не умеет считать деньги — или выдет желаемое за действительное!

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

Вот только заплатят ли разработчикам за свой продукт или они могут его пилить в свободное время бесплатно?

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

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

Словосполучення «кривавий ентерпрайз» декому знайоме і може лякати: монструозний проєкт, легасі-код, бюрократизовані процеси

Ну хоть тут не соврали!

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

Качество очень важно: поэтому в легаси энтерпрайзе всегда четкие требования, прозрачный код, спека на кадждое изменение и 100% покрытие тестами. Никто не лепит костылей и всегда есть мудрый архитектор, который подскажет как сделать красиво. Миф защитан!

Наведені міфи — лише відмовки та обмеження, які ми часто самі створюємо і поширюємо.

Мы в данном случае — это менеджеры ИТ галер, которых интересует только бабло. И которым абсолютно похер на желание развития и само-реализации девелоперов. Погонщикам платят не за это — а за то что бы рабы гребли не отвлекаясь!

Прям набор мифов наивного новичка в айти, которое работает на запад:

По моему опыту и того меньше! Новый код пишу максимум 30% времени. Все остальное — это попытки зарепродюсить баги и найти причину. А еще билды по пол-часа и развертывание по часу. Помимо кодирования — попытки получить ответы на вопросы от автора бага или задачи что же он имелл ввиду.

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

Вот только заплатят ли разработчикам за свой продукт или они могут его пилить в свободное время бесплатно?

В свободное время это продукт разработчиков, а не компании. Никто не заплатит.

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

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

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

Первый этап развития компании «стартап» — когда лепят все очень быстро, чтобы показать инвесторам и получить финансирование. Потом может перепишут при этапе «Масштабирование», но это не точно. Костыли будут всегда. Если делать по вотерфлов с нормальным планированием, то рынок уйдет вперед быстрее чем вы успеете запилить первое полурабочее демо.
Конечно есть разные варианты, иногда специфика и бюджет проектов позволяет сделать «зашибись» сразу, но в общем случае — нет.
В НИИ по госту мы использовали ватерфлов, но там и процес чуть более бюрократизированей и подольше. А тут, извините — динамика свободного рынка и 100500 вариаций агайл.

А если команда в долине и есть, то она не может тащить все и будет делигировать со временем целые направления на аутсорс.

из собственных наблюдений могу сказаить, что «делегируется» почти всегда та часть, которую один разработчик в єтом вашем интеренете метко охарактеризовал так: "Ты хоть раз видел у этих галер нормальные проекты? Не хуергу? Не древнегреческие механизмы? Не шлак писаный обезьяной и глистами? Менеджеров не выносящих мозг и тд?"©

Галеры — отличное место для работы, по мнению галерщика. Ну надо же.

Работал и там и там, люди в плане компетенций в среднем одинаковые. На галерах как-то поменьше ЧСВ у разработчиков, да и процессы поцивильнее.

Где и там и там? И веслал и заправлял галерой?

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

что нам на это отвечает автор:
1. ну это так полееезно и так хорошооо, и вообще то что вы видите и видят другие разработчики это не то.
2. ...
конец

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

Все «мифы» — правда.
Очень странное желание выгородить галеры. Прям стокгольмский синдром.

Є таке дость добре вивченне поняття «корпоративна психопатія» (corporate psychopathy). Психопатія сама по собі — це розлад психіки, що належить до погранічниго спектру розладів психіки (погранічний, бо типу знаходиться між неврозами та психозами), знаних також як розлади особистості, є одним з двох асоціальних розладів особистості (другий — соціопатія). На відміну від усіх інших розладів особистості має у більшій мірі вроджену природу (людина народжується схильною до психопатії) та характеризується наднизькою, іноді повністю відсутньою емпатією — способністю розпізнавати власні емоції та почуття та почуття й емрції оточуючих — і одтак співпереживати людям, підтримувати, любити, проявляти дружність чи м’якість. Це пов’язане з тим, що та частина лімбічної стстеми головного мозку, що відповідає за проживання та розпізнавання емоцій та почуттів, ізольована, не з’єднана чи має поганий зв’язок з мозком.
Такі люди характеризуються окрім наднизької емпатії жорстокістю, маніпулятивністю та надмірним егоцентризмом, повною відсутностю потреб у визнанні збоку. Їхнею метою стає влада, високий статус у тому середовищі, де вони працюють/знаходяться та матеріальні блага. За різними джерелами у попупяції таких людей біля 4%.

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

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

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

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

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

Притому, це все психопати, яким пощастило дорослішати у більш-менш здоровому середовищі, де хоч якісь моральні принципи їм було вкладено.

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

то до чого тут сервісні компанії? Вони теж бувають малі і великі.

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

Отличное замечание. Работал на таком проекте в одном из лидеров рынка. Delivery manager на этом проекте на 100% попадает под описание социопата/корпо психопата. Проект длился около 8 месяцев и заметно подпортил здоровье и нервы большей части комманды — деливери выжимал из девов все соки и потом просто выкидывал перегоревших сотрудников из проекта. Постоянно врал клиенту по поводу готовности solution, подставлял лидов, переводил стрелки на комманду и скрывал имеющиеся дефекты от своего руководства.

Как таких людей распознать и сразу валить — универсального рецепта нет. Для себя отметил что подобные люди чаще всего любят микроменеджить, у них нулевое доверие к членам комманды и часто встречается лизоблюдство перед клиентами и начальством(в случае выше это ещё дополнялось ежедневными(!) отчётами клиенту о проделанной работе которые высылались в 2-3ч ночи)

я відповідаю за Delivery

з цього все і починається, на за Engineering, Development, R&D і т.д., а за ’делівері’, це найкраще робоче середовище для розвитку себе хіба в ’сервісмена’, який вміє ’деліверити’ набагато краще, ніж розробляти/забезпечувати якість

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

Якщо потрібно власне ’деліверити’, то це справді міф.

Проєктування, планування, ознайомлення з готовими рішеннями, врешті-решт R&D і прототипи. А ще документація, тести, зустрічі, демо, естимейти...

PM/TM/Architect, BA/SA, TW, QA, PM...
Навіщо тоді всі ці люди, якщо купу абсолютно чужої роботи треба робити і тобі?Це якийсь нездоровий тренд з цим клятим овнершіпом, коли чітка структура команди, де кожен відповідає за своє, розрушена, і тепер мало того, що ти маєш бути всім потрохи, так і ще й думати чи якось переживати за продукт. З однієї сторони — так, залучення в суміжні сфери типу як розвиток, але з іншої, просування таких тем:

Подзвоніть клієнту та дізнайтеся в нього про бачення продукту, загальну стратегію, користувачів, пріоритети — і ваша робота буде наповнена сенсом, а ви самі навчитеся багато чого і станете співавтором продукту!

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

Якість продуктів, нащо за неї переживати

Очень часто один из серьезных минусов продуктовой компании, как для разработчика — внезапно, сам продукт. И чем этот продукт дольше на рынке и успешнее — тем хуже, вот такой вот парадокс. Потому что принцип «работает — не трогай» никто не отменял, так что добро пожаловать в волшебный мир древних версий языков и фреймворков.
Ещё хуже, если продукт активно использует внутренние in-house фреймворки и/или DSL — скиллы которые приходится развивать и которые абсолютно не востребованы на рынке.

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

Угу, але кого те все застаріле хвилює? Це проблеми аутсорсерів на яких спихнули саппорт :)

Угу, але кого те все застаріле хвилює? Це проблеми аутсорсерів на яких спихнули саппорт :)

Саппорт — это только часть. А кроме саппорта- «новый набор фич, как и предыдущий, как и пред-предыдущий, выпускаем на Java 6, потому как у особо важных клиентов 100500 инстансов в продакшене, которые все обвешаны кастомными плагинами, которые они не хотят или не могут мигрировать по разным причинам»

Во-во, и у такого «продукта» еще сохраняется совместимость с Internet Explorer не последней версии) ибо клиенты им пользуются.

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

А кроме этого — есть еще GDPR, есть продукты, codebase которых выросла из стартапов, и ни разу не пересматривалась, потому что `features first, а техборг не на часі`

Да, ты прав. Как ни странно, в таких компаниях работают разработчики, которые давно уже по скиллам устарели. Как пример, есть продуктовая компания в которой разработчик до сих пор пишет на .net framework 2.0. Продукт долго на рынке, больше 10 лет, главное пользу приносит, внутренности типа не важно. Самое интересное, что он же и написал «фреймворк» на JS (для front-end), который без документации и никто не поймет как с ним работать, кроме него.

Как пример, есть продуктовая компания в котором разработчик до сих пор пишет на .net framework 2.0.

А что, это сильно важно — на каком фреймворке пишет кодер? Типа важнее, чем что именно он пишет?

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

это сильно важно — на каком фреймворке пишет кодер? Типа важнее, чем что именно он пишет?

Для компании — постольку-поскольку. Для кодера — должно быть важно.

Должно быть. Но не в этом случае. В этом случае он говорил про теорему Эскобара)

Для кодера — должно быть важно.

Важно для чего? Для домашних пет-проджектов?

Когда кодер приходит на коммерчский проект — никто не даст переписать ему тонны существующего кода, на его (кодера) любимом фреймворке.

Я б за 10-ку в мес и на первом дотнете писал бы :-)

Мне раз Cobol предлагали, я бы и за 10к не согласился.
Если год писать на Cobol за 10к, потом закроется проект, и не найдешь работу, и второй год, или пол года будешь учить новые технологии.
И ЗП за 2 года будет не 10 а 5к, или 7.5к в крайнем случаи, которые и на последнем .NET реально получать, плюс меньше стресса, и позора в резюме, и стаж с новыми технологиями поможет получить больше ЗП на них же.

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

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

За 10к еще и на должности тимлида явно не 2 часа в день работать будешь, там были явные намеки на овертаймы.

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

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

достаточные чтобы пройти интервью

если достоверно умеешь в кобол на ваксе и можешь подтвердить хотя бы год опыта в этом направлении, то на временном масштабе, сравнимом с продолжительностью жизни, без работы не останешься ;)

Якщо готові платити 10к включно за час, коли я вчитиму кобол, то чому ні? По великому рахунку на чому писати різниці нема, а кобол крута штука хоч би для сівішки ))) Ну зміниться за той рік-два пару версій умовного спрінга чи ангуляра, ну так перестрибнеш відразу на актуальну )

По великому рахунку на чому писати різниці нема, а кобол крута штука хоч би для сівішки

У меня есть Кобол в CV (и с рабочим опытом, в течении полугода) — ещё с 90-х. Но не пригодился. :)

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

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

Если идеально ASP.NET MVC 5 и ASP.NET Web API 2 знаешь, и OWIN Middleware юзал с ним, то на Core сходу возьмут, особенно если проект c SPA.
Облака нужны на 80% проектов обычно, но видимо у тебе или облака не было, или были девопсы, попал как раз на те 20%.

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

Без здания Task DataFlow, или Akka, или Orleans будешь свои сложные задачи делать через треды, и в итоге не сделаешь. Без знания баз, будешь юзать базы через жопу, и тоже все будет медленно.

Ну может ты и не сделаешь или сделаешь через жопу, тебе лучше знать ;-)

Ну типа SPA сайт можно и на JQuery написать вместо Angular, но писать придется дольше, и работать будет с багами.

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

Если писать что-то большое на фреймворках прошлого поколения, то багов будет больше, и разработка будет дольше.
Это касается и фронта и бека.
Если писать большую систему на .NET или каком-то современном языке, то багов будет меньше, чем если писать на чистом C или ассемблере.

«Начал за здравие а кончил за упокой». Но я тебе помогу ;-)
Я в начале отписал, что не устареешь если не будешь надрачивать фреемверки и причина сему очень проста — все они основаны на том же комп сцаенс и 100500 заюзаных паттернах, попробовав несколько разных фреемверков легко изучишь другой, потому как сами эти фреемверки решение класических проблем используя класические подходы просто немного в других комбинациях, ничего революционного они не изобретают, поэтому когда есть хороший опыт и познания CS то ничего у тебя не устареет.
А если ты просто зубрила тех документации, то конечно придется зубрить всю жизнь, а главное что проходить собесы ты будешь всегда у таких же зубрил с соответсвующими проектами.

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

Это всё справедливо, но, увы, только в теории.

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

Як часто у вас міняють СТО?

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

В мене подібне враження, від 1.5 місяця на щось просте (типу фінансова математика на базовому рівні), 3-х місяців на складніше (QNX) і пів року на всякий Haskell.

я хз что вы там такого в этих фреемверках не можете понять за первые три месяца проекта.

Нет проблемы разобраться во фреймворке за три (а то и полтора) месяца.

Есть проблема в том, что никто не готов эти полтора, а, тем более, три месяца ждать — ибо сроки «на вчера».

Так-то, я сам в конце этой зимы разобрался «в бою» с NodeJS / NestJS за пару-тройку недель, имея за плечами опыт с ASP .NET Core, и в одно лицо написал несложный бэкенд.

Но три недели — не три месяца... Три, и даже полтора месяца в той ситуации означали невзятие стратегического для компании проекта.

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

Этот комментарий нужно в тему которая «развенчивает» мифы о галерах :)

Не в том мире такое требование) там ищут джунов, чтоб разбирались в самописном «фреймворке» без документации)

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

Тут далеко не последний -фактор — психологический. Типа, «я тут работаю уже 5 лет, все модули, функции и зависимости знаю на память, я практически незаменимый специалист по продукту (что кстати очень часто правда), зачем мне еще напрягаться и что-то учить».
Встречал такое много раз. И потом — такие люди сами начинают активно противиться новому, даже если появляется реальный шанс что-то изменить — потому что подобный менталитет быстро прививается и тяжело уходит

Прикинь, это мало того, что ты описал. Такие разрабы будут не рады стронг джунам или миддлам, которые им скажут, что надо новые технологии или фреймворки пропихивать в продукт. На моей памяти там еще использовали CVS, и только когда пришел в команду молодой стали юзать Git — ему понравилось. Психология зрелого законсервированного человека — зачем учить что-то новое, если уже все обкатано?

А зачем менять если и так работает? Тут бест матчь — разрабам нравится и бизнесу не нужно пихать новые фреемверки которые делают все тоже самое.

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

Так смысл же не в том чтобы пихать новое просто потому что хайп и стильно-модно-молодежно, а в том, что при миграции на +1 мажорную версию того же фреймворка — это одни трудозатраты, а при миграции на +3 ( когда в конце концов наступает end of life / end of support )- чаще проще переписать с нуля

Це як знайомий їздив у відрядження робити презентацію архітекторам компанії... увага!... юніт-тестів та депендесі-інжекшн!

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

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

Абсолютно так.

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

я когда то про это целый гневный топик родил
dou.ua/forums/topic/5833

Карантин показав, що основною цінністю сервісної компанії це є її можливість найти клієнта, який би ніколи не найняв в Україні напряму (поки що). От і все ))

Якби ти не крутив, якби клієнт тебе не любив ти все одно завжди будеш контрактором, якого зможуть швидко звільнити, або якщо компанія поб’є горшки із клієнтом, то тебе просто заберуть від них. Якби ти не хотів відповідальності, завжди буде межа, де тобі скажуть, вибач, але контрактори не можуть це робити, ми не можемо це довірити контрактору і тп. Я вже не говорю про додатковий оверхед, який компанія насаджує своїми внутрішніми приколами у вигляді промоушенів та політикою роботи із клієнтом (намаганням заробити більше грошей на ньому). Ну і карєрний ріст, або в ПМи або в архіткети — тому таке собі. В колег із США, Канади та Європи, досить більше можливостей ніж у нас в плані кар’єри.

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

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

Но да, не укро-контрактор.

А акції компанії у вас дають?

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

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

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

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

Много комментариев, типа вашего, сродни гребцу, который мечтает стать яхтенным капитаном но стоящему почему-то посреди площади с длиннейшим веслом и кандалами на ногах и вопящему «я грёб, гребу, и буду грести!»

Отношение определяет результат. Если для вас сервисная компания — это «грести» таски, которые вы тихо ненавидите на самом деле, тогда вопрос а что вы там 4 года делали? Сколько за 4 года вы внесли предложений стартануть новое направление, возглавить что-то, или создать новый продукт?

Хех, дуже точно все описано)))

Все вышеописанные тезисы про разрушения мифов о галерах применимы в основном только к мелким галерам и коммандам. В крупных галерах все мифы как раз реальны (и оттуда собственно и пришли).

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

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

Как для начинающих «войтивайтишников» — крупная галера это самое оно.

Но для продолжающих, есть смысл выбирать между 1) продуктовиками (западными) 2) прямой работой на клиентов (западных).

Как для начинающих «войтивайтишников» — крупная галера это самое оно.

опечатка в слове «дно»

На крупной галере 1) налаженные процессы 2) налаженное обучение тушек 3) череда проектов. Что ещё нужно ИТ-нубу?

Но это хорошо первые пару-тройку лет. А далее, смотреть...

Но это хорошо первые пару-тройку лет. А далее, смотреть...

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

От в цьому теж криється проблема сервісних компаній.

От в цьому теж криється проблема сервісних компаній.

Так а в чому проблема? Не хош брати участь в цьому — не бери. Можна собі сидіти на одному проекті і не відсвічувати.
А так кожні півроку, новий проект, де ти бачиш — та + різних підходів, технологій, архітектур, CI, cloud providers, тулів, etc.
Як то кажуть

I’ve seen things you people wouldn’t believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser Gate. All those moments will be lost in time, like tears in rain.

В сервісних компаніях дійсно є позитивні моменти, але це не зовсім те, про що ви пишете.
Спробую перерахувати з точки зору рядового українського розробника:
1. Можливість роботи над продуктами і проектами із ЄС, США та іншого світу, які б розробник без аутсорс контори ніколи б не отримав.
2. Відповідно, витікаючи з першого пункту, зарплата — грошовитий проект в аутсорсі може платити багато, особливо багато якщо розробник компетентний, а на проекті горить.
Продукти часто не готові стільки платити, як аутсорс в якого горить.
3. Можливість найматися і звільнятися швидко. Набрид проект? Вигорів? Отримав офер на +500? Два тижні нотісу і тримайтесь, здоров’я вам, всього найкращого.
Звісно, для збереження хороших відносин і «обличчя», так робить рідко хто, але можливість є, а це головне.
4. Можливість отримання оферу за декілька днів. В аутсорсі часто все просто: Тебе знайшла ейчар, провела скринінг, технічна співбесіда, опціонально розмова з клієнтом чи менеджером — офер. При бажанні, це можна впихнути у 2-3 дні. Продукти ж їх багатораундовими інтерв’ю, cultural fit та тижнями роздумів втрачають багато кандидатів.
Не буду стверджувати, що це добре для компанії, не проводити повноцінного адекватного відбору, але якщо робота треба швидко — можеш отримати швидко.
5. Можна досить швидко рости по кар’єрній драбині. Якщо є бажання і ти себе добре проявляєш, нічого не завадить за рік-два вирости з джуна в мідли, за два-три з мідла в сіньйора, потім в ліди, архітектори і т.д.
Аутсорсери з постійно ростущими проектами потребують багато нової крові і у вчорашнього розробника багато можливостей стати завтрашнім лідом чи менеджером. Головне, мати ціль і працювати над нею, а також декларувати свої наміри менеджменту.
Ви можете бути не найкращим перформером або не найприємнішим у колективі, але коли контора потребуватиме нового ліда чи менеджера, з великою ймовірністю візьмуть того, хто сам проявлятиме ініціативу до цього.
6. Можливість посидіти на бенчі отримуючи зарплату і в принципі нічого не роблячи.
Мабуть, можна придумати ще якісь плюси.

Варто сказати, що ІТ індустрію України з тим всім, що є, сформували аутсорсери, за що я їм вдячний.

Запускайте програми опціонів та 4 денний робочий тиждень і тоді в аутсорсерів буде ще більше переваг)
Я вже тут писав, що перший великий аутсорсер який зробить 4-денний робочий тиждень, зніме всі вершки з ринку кандидатів.

1. Можливість роботи над продуктами і проектами із ЄС, США та іншого світу, які б розробник без аутсорс контори ніколи б не отримав.

Ну такой себе бенефит, как говорить если бы разработчик не получил резиновой женщины, то он бы женщин вообще бы никогда не увидел. Нужно всегда помнить, что ключевые продукты не отдают на аутсорс. Всё ценное и генерирующее value делают in-house.

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

Это сублимация. Ты подменяешь локальная продуктовая компания, которая ещё и пилит бюджет, например, и западная продуктовая компания, которая отдаёт на аутсорс. Но абсолютно выкидываешь из рассмотрения западную продуктовую компанию, которая работает в Украине.

3. Можливість найматися і звільнятися швидко. Набрид проект? Вигорів? Отримав офер на +500? Два тижні нотісу і тримайтесь, здоров’я вам, всього найкращого.

Ну это как пилить себе ногу и радоваться что дают бесплатный морфий :) Не будет треша, не будет таких массовых выгораний, не будет нужды бегать в поисках нормальных проектов. Не нужно забывать, что западные продуктовые компании могут платить большие деньги, включая стоки чем аутсорсеры. Из минусов у них есть заморозка зарплаты при увольнении и бан на возврат на 1-2 года. Т.е. прыгнул на +500, захотелось назад, жди 1-2 года и вернёшься на ту же зарплату, что у тебя и была.

5. Можна досить швидко рости по кар’єрній драбині. Якщо є бажання і ти себе добре проявляєш, нічого не завадить за рік-два вирости з джуна в мідли, за два-три з мідла в сіньйора, потім в ліди, архітектори і т.д.

Это как вешать самому себе медальки, а потому при реальном собеседовании удивляться почему сеньора с 5 годами опыта позиционируют не выше миддла. Инфляция тайтлов — это огромная проблема аутсорса, т.к. используется для мотивации вместо того чтобы повышать зарплату.

6. Можливість посидіти на бенчі отримуючи зарплату і в принципі нічого не роблячи.

В продуктовых тоже есть «бенчи», но не для всех.

Варто сказати, що ІТ індустрію України з тим всім, що є, сформували аутсорсери, за що я їм вдячний.

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

Всё ценное и генерирующее value делают in-house.

Необязательно. Мне самолично знаком пример компании, делавшей UI для ультразвуковых аппаратов (медицина) Сименсу, Филипсу и Тошибе. При этом, делали у себя в офисе (аппараты им туда присылались).

Правда, потом их за кучу бабла купил Филипс — но это было уже через более 10 лет такой работы.

П.С. Собственно, я и сам сейчас так работаю. У меня дома тоже присланный мед-аппарат — и я его мучаю. А все ресурсы компании (заказчика) — перекинуты с этого проекта на другие.

делавшей UI для ультразвуковых аппаратов

Вот ты сам себе и ответил про генерирование value. Где UI и где начинка ультразвуковых аппаратов. Epic Games тоже делает UI для General Motors: techcrunch.com/...​e-for-next-gen-interface , это безусловно немаловажная часть современного авто, но сравнивать морду с начинкой авто и ставить их на один уровень совсем некорректно :D

Где UI и где начинка ультразвуковых аппаратов.

Начинка (оборудование и firmware) — это не мой профиль. Да и не твой тоже. И не той конторы, делавшей UI. Собственно, и не укро-галер тоже.
Мы ведь, всё-таки софтокплепание обсуждаем.

Mой поинт в том, что если хорош в делании софта — заказчик изыщет возможности, чтобы тебя привлечь. Даже если ты не хочешь/не можешь работать у него " in-house".

А як QSSL скотилася з керування реакторами до морди інфотейменту в авто?

А як QSSL скотилася

Тут каждый решает для себя скотилась или поднялась. Это как раз две стороны медали продукта. С одной стороны — реакторы — это круто, престижно, раздувает чувство собственной значимости но там у многих стоит ещё QNX 4.22 1995 года выпуска с восьмым ватком компилятором, новые реакторы каждый день не запускают, откуда брать деньги на развитие продукта? Это почти как кобол, там время заморожено практически навсегда.

С другой стороны авто-промышленность, консервативная, но в меру, а если сравнивать с атомной промышленностью, то там вообще одни инновации. QNX в качестве инфотеймента мало кто использует. Сейчас мы единственная полностью сертифицированная платформа для digital instrument cluster с хайпервайзером. Мы просто пускаем андроид внутри себя для android-auto, или apple car play, и они занимаются развлечением пользователей. Автопромышленность по доходности, наверное, один из самых прибыльных легальных бизнесов. Недавно я протащил Vulkan в QNX, чтобы заменить OpenGL ES, практически все гейминговые компании, которые работают на авто-индустрию в том числе, сразу заявили, чтобы будут переходить на Vulkan для automotive. А если ещё и говорить про инновации в виде ADAS и autonomous cars, то тут легаси кода вообще нет, одно сплошное R&D.

Саме тому в нас суцільне R&D на базі Linux.

Бо ще раз 9 місяців добиватися виправлення критичної баги в закритому ядрі я не хочу.

З іншого боку, цирк в нас 18 років на QNX (зараз 7.1), політ нормальний.

Бо ще раз 9 місяців добиватися виправлення критичної баги в закритому ядрі я не хочу.

А это зависит от того кто платит, тот девушку и танцует :D Для заказчиков, которые сидять на custom engineering время реакции от пары дней до пары недель в зависимости от риквеста. Багов тяжелых практически нет уже давно. Ну и реакция под Линуксом будет такая же и совсем небесплатная, в среднем по палате даже хуже, дольше и дороже. Не просто так все игроки на рынке embedded трятят сотни миллионов долларов суммарно на поддержку Yocto Linux, потому что с остальными каши не сваришь, а потом когда выясняется что за пару миллионов они получат тоже самое у нас, многие бегут так, что аж пыль стоит :D

Це я про 2004-й. Але бага була епічна, ми півтора року жили на приватному билді ядра 6.3.1

Дєвушку тоді танцювало CISCO, якщо не помиляюся.

Раньше была чисто продуктовая модель существования компании, любые изменения протаскивали по всем процессам, а это очень долго. Сейчас у нас смешанная продуктово-сервисная модель. Если потреблять GA (general availability) продукцию, то да где-то 3-9 месяцев до того как исправление увидит весь мир, а если Custom Service Plan, то всё очень быстро происходит. По крайней мере такое нравится больше всем и заказчикам и разработчикам.

Ну такой себе бенефит

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

Это сублимация.

Сублімація не сублімація, але краще сублімувати із хорошим рейтом ніж без нього.

выкидываешь из рассмотрения западную продуктовую компанию, которая работает в Украине

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

Ну это как пилить себе ногу и радоваться что дают бесплатный морфий :)

Якщо продовжувати вашу аналогію, то це відпилювання собі ноги з перспективою встановлення біомеханічного імпланта який дозволить тобі бігати швидше на +5 м/с. Хтось скаже нафіга, сидів би спокійно з обома ногами і повільно тренувався, а кому треба швидше і згідний на заміну ;)

Инфляция тайтлов — это огромная проблема аутсорса,

Тут згідний, нажаль, інфляція йде повним ходом. Але тим не менше, це не причина не осідлати цю хвилю)

В продуктовых тоже есть «бенчи», но не для всех.

Мене якось навіть мідлом більше місяця тримали на бенчі, хоча по скілам був все ще ближче до джуна. Навряд продукти можуть собі це дозволити. Тому тут теж + аутсорсерам.

Когда начинаешь понимать какой могла бы быть ИТ индустрия

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

Навряд продукти можуть собі це дозволити.

Сложно сказать, насчёт укро-продуктов — но западные продукты могут себе позволить очень многое. У них мультипликатор прибыльности — 2х/3х и более на тушку (не сравниться с галерными 20-30%).

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

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

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

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

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

Сублімація не сублімація, але краще сублімувати із хорошим рейтом ніж без нього.

А ещё лучше с хорошим рейтом и стоками.

Навряд продукти можуть собі це дозволити. Тому тут теж + аутсорсерам.

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

Ніякою, вона могла бути або такою як зараз або ніякою.

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

Я помню её другой. Я помню проекты, которые требовали сильную экспертизу и помню где-то 2002-2004 года, когда такие проекты переставали завозить,

Я тоже помню те западные проекты с «сильной экспертизой» в Украине.
Решение «проблемы 2000-го года», для западных заказчиков — когда в конце 90-х тысячи укро-мэйнфреймщиков/коболистов внезапно нашли работу, да ещё и за кучу бабла (по тем временам). Ну, и не только они.
Это «проекты с сильной экспертизой»?

А других проектов — не было ни тогда, ни позднее.
Кто хотел чего-то более серьёзного — валил в Корею в Самсунг на несколько лет (это было массовым).
У кого был английский/немецкий + хороший скилл — несколько укро-галер депортировали в долгодействующие командировки (перетекающие в ВНЖ) в Швейцарию/Германию.
Ну и Штаты/Канада, понятно.

В общем-то, то что сейчас предлагается на укро-галерах в Украине — это небо и земля, в сравнении со шлаком 90-х/начала 2000-х.

Я помню проекты, которые требовали сильную экспертизу

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

Продукти часто не готові стільки платити, як аутсорс в якого горить.

Весь профіт отримає власник галери, а не гребець. Але гребцю мусить бути від цього трохи тепліше на душі, це так...

3. Можливість найматися і звільнятися швидко.

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

4. Можливість отримання оферу за декілька днів.

О, «стабільністю» запахло... Ти джунам краще розкажи, які з 10ї спроби тільки в компанію попадають.

5. Можна досить швидко рости по кар’єрній драбині.

Ага, 23-річний сіньор, який нічого не знає, але дуже впевнений в своїй необмеженій крутості, це як раз результат таких ось просувань по «драбині».

6. Можливість посидіти на бенчі отримуючи зарплату і в принципі нічого не роблячи.

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

С одной стороны опционов у нас продуктовые не дают так, что разница не велика, а с другой все-таки прослойку посредников кормят из зп программистов :) а вообще работать приходится на непосредственного начальника, а его качество от продукт/аутсорс мало зависит

Бракує розуміння продукту? Запитай!

ain’t your business

Незрозумілі бачення і пріоритети? Запитай!

ain’t your business

Does anyone have any questions? No?

Row, row, row your boat
Gently down the stream
Merrily, merrily, merrily, merrily
Life is but a dream

Soon may the Wellerman come
To bring us sugar and tea and rum
One day, when the tonguing is done
We’ll take our leave and go

Look down, Look down
Don’t look ’em in the eye
Look down, Look down,
You’re here until you die

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

Бракує розуміння продукту? Запитай!

Незрозумілі бачення і пріоритети? Запитай!

Не відповідають — нагадай, пропонуй варіанти, ініціюй дискусію

Хочеш +500 — нє ну ви нє панімаєтє, єто другоє, для вас очень большая честь работать на нашей галєрє, тєм болєє, что новая пасія СТО хочет сєбє імпланти і квартіру в центрє, так что лучше поовєртайміте немножко, вместо єтіх мерзкіє +500.

Сокращу до смысла: Вы не понимаете, это — другое!

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

Зачем? У него будет с чем сравнивать, он свалит в ужасе от бардака и сопротивления менеджмента что-то менять на интересном продукте)))
Я потратил 3 часа и так и не смог объяснить манагеру в продуктовой компании что такое jira-flow и зачем его настраивать. Просто компания на своём велосипеде 20 последних лет без изменений педалит и им нормас.

Опять же, продукт продукту рознь. За весь свой опыт был в 5-ти продуктах и в одном аутсорсе (текущее место работы). Вывод — аутсорс очко и зря я сюда полез. Как раз-таки на «нормальном» продукте все процессы меняются настолько быстро, насколько команде становится неудобно что-то делать. Если в вашем случае jira-flow была предложена чтоб просто что-то предложить, а команда и без него работала отлично все 20 лет, то думаю проблема в вас. Но не отрицаю что есть донные продукты :)

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

Как итог куча бесполезных " (хепинес, шмепинес и т.п.) менеджеров", присосавшихся к денежным потокам заказчика и, в лучшем случае не делающих ничего полезного, а в худшем, мещающих работе заказчика с непосредственным исполнителем.

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

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

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

Каждая команда пишет на чем хочет?

гибкость в работе с заказчиком,

C каким именно? Продукт в классическом понимании разрабатывается для максимально широкого рынка.

Чому сервісна компанія — найкраще робоче середовище для більшості інженерів

Статтю не читав, але навряд чи вона відрізняється від тих що тут були протягом останніх 10 років.

Тому важливі тези:
1) Якість робочого середовища не залежить від типу компанії, а залежить від культури
2) Досить часто аутсор компанії мають ряд обмежень у
— можливостях прийняття рішень;
— візібіліті для бізнес стейкхолдерів і як результат у кар’єрному рості.

Руйнуємо міфи про «галери»

Міт перший: галера — це синонім аутсорсу. Насправді ні. Галера — це будь-яка, зазвичай велика, контора де працівник є більше частиною механізму, а не незалежний контриб’ютором. Умовний Гугл — це галера, а контора ДХХ — не налера.

1) Якість робочого середовища не залежить від типу компанії, а залежить від культури

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

Статтю не читав

на цьому плюсанув, далi не читав

Автор, поправте, будь ласка, слово «Міф»

Треба веслувати, не можна керувати. Мій третій

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

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

В продуктовых компаниях ты тоже можешь легко столкнуться с такими-же проблемами)))

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

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

не все продукты это стартап, стартап это один из этапов развития любой компании, который проходит буквально за пару лет. Так-же надо понимать что 9 из 10 стартапов просто помирают не выходя из этой стадии.

Це нонсенс, бо з’явиться занадто багато специфіки та різних додаткових витрат.

Якщо в компанії США є людина, з аутсорсингового хабу, як Індія чи Україна і т д (яких зараз в США хоч греблю гати). Виявиться, що витрати не такі великі, а віддача від гребців буде вища.

Чому сервісна компанія — найкраще робоче середовище

очевидно тому що ви

відповідаю за Delivery у сервісній компанії Proxet

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

Все інше то раціоналізація цього простого факту.
Успіхів вам і далі з перепродажом лавок та весел західним партнерам.

У меня к сожалению достаточно мало опыта работы в продуктовых компаниях, но уринотерапию мне проводили больше именно там. Да и тут по статьям СЕО и других директоров продуктовых компаниях уринотерапия прям с экрана монитора льётся. Хотя, опять-же я только по своему домену говорю.

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

бла бла про большую честь работать у нас
вы платите главное

так платим же, кто ж с этим спорит ? =)

Если сунутся в Дию, то будет и 8-10к. Грывэнь.

а где в продуктах реально 8-10к платят?))) Ну да, есть пару ничем не подкрепленных заявлений СТО что отдельным представителям платят такие зп, тем не менее даже в глобале(по отзывам) есть пара-тройка человек с подобными зп. Которые впрочем никак не влияют на общую статистику, так как и продукты и аутсорсинг ориентируется на те-же самые данные исследований рынка.(Конечно это не опросник на доу, впрочем данные весьма близки)

а где в продуктах реально 8-10к платят?))

на верхней палубе

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

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