Вы предлагаете заказчику свои услуги. И отдаете копеечку в адрес вашего аутсорса за его услуги вам.
Бизнес аутсорса/аутстаффа завязан на том, что он предлагает разработчикам более интересные условия, чем может предложить усредненный заказчик. И поэтому он получает возможность аккумулировать у себя множество интересных разработчиков, которых нет на рынке труда, до них не может добраться заказчик.
Вам же бенчи оплачиваются? Оплачиваются. Репутация у бренда вашего аутсорса хорошая? Хорошая. Продажники продают? Продают. Ресурсный менеджер работает? Работает. HR работает? Работает. Вы получаете доступ к заказчикам, которые работают преимущественно с аутсорсом и не берут людей с рынка? Получаете. Вот это все в совокупности и составляет то, за что вы делитесь с аутсорсингом копеечкой.
Скорее всего, в процессе того как заказчику предлагают использовать конкретного разработчика, который обладает определенным набором характеристик, определенными условиями применения и определенной ценой — этого разработчика называют каким-то другим термином. Не товаром.
Не использовать. Резюме, ресурс-менеджеры — это просто такой инвентарь, чтобы быстрее получать работу. Вы вступаете в обычные рабочие отношения с заказчиком, просто в ускоренном темпе.
Так бы вы на поиск и окучивание заказчика потратили недели, а так вам чики-пуки-шпили-вили — все готовенькое на блюдечке, напрягаться не надо.
Можно провести аналогию с биржей. На бирже же торгуются реальные товары, реальные акции, реальное все. Просто оно настолько автоматизированно, что создается впечатление нереальности происходящего, как будто бы оно не с вами происходит, а где-то «на рынке».
Я не обижаюсь, но это оскорбление. Я себя товаром не считаю. У товара выбора нет, а у меня есть.
Мой пример был к тому, что вы не только согласились на конкретный проект, но также выразили желание через резюме работать над группой проектов. И тот проект, над которым вы работали подходил под ваши желания.
Кстати, как в SCRUM-е решается вопрос, что каждый из разработчиков имеет разную направленность и разный стек технологий, но при этом все разработчики равноправно голосуют за оценку Пользовательской истории в баллах?
Вы работаете над проектом в целом. И у вас в голове есть модель всего проекта, а не только своего куска. Оценка — это просто такой повод синхронизировать модели. Если кто-то что-то недопонимает — это наверняка отразится на оценке.
Интересного в каком плане? В плане «утащить к себе в норку»? Этого навалом, да. А так, чтобы еще и PR-ы получать в ответку — таких проектов совсем не много. Думаю, сотни на весь гитхаб.
Я работал как раз в аутсорсе/аутстаффе крупном. У меня всегда спрашивали.
Развернуться и уйти — это будет как в анекдоте про цыгана в партизанском отряде — «Эти ваши листовки — очень плохой товар, я еле их продал».
Ну вы же не товар на самом деле. Вы сами себя воображаете товаром, а потом страдаете, что выбора нет.
У меня как было: у меня было резюме внутри компании. И ресурсный менеджер показывал это резюме заказчикам. Не обычное мое публичное резюме на hh, а именно специальное. И там было все написано, что могу, что не могу, и так далее.
ИМХО, «Independent self motivated» — совсем не означает, что каждый разработчик из команды должен кроме программиста быть еще и Проект менеджером и Архитектором и Техническим писателем. Рискую нарваться на «минуса в карму», но такое совместительство как минимум тупо не оплачивается…
В скраме нет подразделения на должности, есть только разработчики. Если команде не достатет навыков для работы — это один вопрос, и серьезный. Но его надо решать еще до начала работы.
Ну вас же не под дулом пистолета работать заставляли. Вас спросили «будешь участовать?» вы ответили «буду». Даже если вы вначале согласились, а потом передумали, вас никто не держал.
Independent self motivated
Вот как раз требование в вакансии на эту тему есть.
Возможности напрямую обсудить с заказчиком его «пожелания» лично у меня нет, как нет такой возможности и у других разработчиков из команды. Собственно, обычная «галера» и обычные условия работы программистов…
Ну как же нет? На планировании итерации присутствовал владелец продукта. И вы выбрали эту задачу. У вас было время и обсудить и решить как именно делать и все остальное.
Это у вас какой-то циничный взгляд. Крупные корпорации не обязаны ничего выкладывать, и уж тем более тратить ресурсы на втягивание комьюнити PR-ов к себе. Это они делают чисто по доброте душевной.
«они нам протестируют, пофиксят, и может быть даже разовьют софт, а мы будем стоять во главе процесса, и рулить, куда нам надо»
Раньше с таким лозунгом в некрупных компаниях продавали руководству выкладывание своих наработок в опенсорс, но практика показала, что если вы не гугл, ваша работа просто не будет никому интересна.
Она сама собралась. То есть, каждый член команды по отдельности согласился делать этот продукт для этого владельца.
В скраме нет никаких дополнительных должностей, кроме разработчика. Но, компетентность, конечно, есть. Если команда оказывается неспособна выполнить требования, это выяснится на первом же планировании итерации и придется срочно решать эту проблему.
Мастер показывает задачу команде, спрашивает — «вы готовы взять на себя обязательство выпустить эту задачу?». Команда говорит — «готовы».
Архитектора в команде не предусмотрено — кто должен заставить заказчика правильно сформулировать свои Пользовательские истории?
Можно просто не брать плохо сформулированные пользовательские истории в работу. В статье речи вообще не идет про пользовательскую историю. В той формулировке, как написано в статье — это просто буллшит какой-то.
А какая разница? Если команда показала неудовлетворительный результат, ее просто распустят, и, если необходимость в разработке не отпала, соберут новую.
Это же детство — рассчитывать, что за вас кто-то будет другой думать. Сбору и анализу требований учат в вузе, любой разработчик это умеет.
Ну так правильно. Потому что задача изначально некорректно поставлена. Вы приняли пожелание заказчика за пользовательскую историю. Отсюда и мнимое противоречие.
Пользователь не хочет никакой системы получить. И уж тем более, ему плевать на блокчейн. Нужно не нафантазировать, что он хочет, а пойти и спросить у него и бережно записать.
Блокчейн нужен, если есть какая-то пользовательская история, которую невозможно сделать без блокчейна, но очень хочется. А не просто так от балды.
Пользовательская история — это запись требований в таком виде, чтобы каждому был очевиден буллшит в постановке задач. Чтобы уборщица посмотрела в бэклог и могла сказать: «так не бывает, так живые люди не делают». «Добавить блокчейн» — никому не нужен блокчейн. «Я, как начальник участка хочу видеть, кому нужно всыпать люлей за низкую производительность» — вот это по-нашему.
Я вот сейчас пишу UI на питоне. Без реакта. Слезы наворачиваются.
Вы про искусство. Я же профессионально работаю фронтенд-разработчиком. Каждый день по 8 часов в день последние несколько лет. В работе реально помогает. Я и на ejs писал и на ангуляре первом — это все не то. Перечислять отличия бессмысленно, потому что все то же самое можно было сделать и раньше. Просто не удобно. Больше кода, больше ошибок, сложнее отлаживать, больше всяких нюансов неочевидных.
Ну, не буквально, конечно, в гугле и фб, но в таких же крупных компаниях я работал. Одна на 15 000 сотрудников, другая на 8 000. Причем, вы удивитесь, но там как раз пишут на реакте и на ангуляре. А на Vue и на Svelte не пишут. Так что, да. Я фейсбук.
Ну да. Сотни разработчиков в фейсбуке и столько же в гугле дураки и не понимают ничего. Конечно же Брин с Цукербергом подписали циркуляр, в котором приказали пользоваться именно реактом и ангуляром.
А я и не критиковал 1С. Я написал лишь то, что React и ангуляр решают реальные проблемы разработчиков. А многие другие фреймворки/библиотеки решают лишь проблему чем бы заняться их авторам на досуге.
Ваша статья ровно точно такая же субъективная и с передергиваниями, как и оригинальная.
Svelte, как и Vue — это просто развлечения их создателей, форма искусства, оторванная от практики. Как искусство они очень хороши, их изучать — одно удовольствие.
React и Angular — реальные инновации, они полезны экономически. Это просто совсем другой уровень. Комьюнити и коммерческие проекты — очень разные. И авторы комьюнити фреймворков принципиально не могут посмотреть на крупные коммерческие базы кода, их просто туда никто не пустит смотреть. Если их, конечно, не наймут в одну из таких компаний. Гвидо ван Россум сделал питон, потом его наняли в Google и он смог наблюдать, как его язык используется на практике и сделал python3, который стал конфликтовать с 2.7.
Можете сколько угодно писать, что Svelte «такой же, и даже лучше», но в действительности, единственная причина его появление — автору было скучно. Завтра он найдет себе другое занятие и кончится весь Svelte.
Вы по-сути задаете мне вопрос «чем бытие лучше небытия?». Черт его знает, если честно. Мне интересно посмотреть что там дальше будет.
Молча грести и превозмогать. Если будете жаловаться, просто потратите больше сил в данной ситуации (не все жалобы бесполезны).
Бизнес аутсорса/аутстаффа завязан на том, что он предлагает разработчикам более интересные условия, чем может предложить усредненный заказчик. И поэтому он получает возможность аккумулировать у себя множество интересных разработчиков, которых нет на рынке труда, до них не может добраться заказчик.
Вам же бенчи оплачиваются? Оплачиваются. Репутация у бренда вашего аутсорса хорошая? Хорошая. Продажники продают? Продают. Ресурсный менеджер работает? Работает. HR работает? Работает. Вы получаете доступ к заказчикам, которые работают преимущественно с аутсорсом и не берут людей с рынка? Получаете. Вот это все в совокупности и составляет то, за что вы делитесь с аутсорсингом копеечкой.
Не использовать. Резюме, ресурс-менеджеры — это просто такой инвентарь, чтобы быстрее получать работу. Вы вступаете в обычные рабочие отношения с заказчиком, просто в ускоренном темпе.
Так бы вы на поиск и окучивание заказчика потратили недели, а так вам чики-пуки-шпили-вили — все готовенькое на блюдечке, напрягаться не надо.
Можно провести аналогию с биржей. На бирже же торгуются реальные товары, реальные акции, реальное все. Просто оно настолько автоматизированно, что создается впечатление нереальности происходящего, как будто бы оно не с вами происходит, а где-то «на рынке».
Я не обижаюсь, но это оскорбление. Я себя товаром не считаю. У товара выбора нет, а у меня есть.
Мой пример был к тому, что вы не только согласились на конкретный проект, но также выразили желание через резюме работать над группой проектов. И тот проект, над которым вы работали подходил под ваши желания.
Вы работаете над проектом в целом. И у вас в голове есть модель всего проекта, а не только своего куска. Оценка — это просто такой повод синхронизировать модели. Если кто-то что-то недопонимает — это наверняка отразится на оценке.
Ну вы же не товар на самом деле. Вы сами себя воображаете товаром, а потом страдаете, что выбора нет.
У меня как было: у меня было резюме внутри компании. И ресурсный менеджер показывал это резюме заказчикам. Не обычное мое публичное резюме на hh, а именно специальное. И там было все написано, что могу, что не могу, и так далее.
В скраме нет подразделения на должности, есть только разработчики. Если команде не достатет навыков для работы — это один вопрос, и серьезный. Но его надо решать еще до начала работы.
Вот как раз требование в вакансии на эту тему есть.
Ну как же нет? На планировании итерации присутствовал владелец продукта. И вы выбрали эту задачу. У вас было время и обсудить и решить как именно делать и все остальное.
Раньше с таким лозунгом в некрупных компаниях продавали руководству выкладывание своих наработок в опенсорс, но практика показала, что если вы не гугл, ваша работа просто не будет никому интересна.
В скраме нет никаких дополнительных должностей, кроме разработчика. Но, компетентность, конечно, есть. Если команда оказывается неспособна выполнить требования, это выяснится на первом же планировании итерации и придется срочно решать эту проблему.
Мастер показывает задачу команде, спрашивает — «вы готовы взять на себя обязательство выпустить эту задачу?». Команда говорит — «готовы».
Можно просто не брать плохо сформулированные пользовательские истории в работу. В статье речи вообще не идет про пользовательскую историю. В той формулировке, как написано в статье — это просто буллшит какой-то.
Это же детство — рассчитывать, что за вас кто-то будет другой думать. Сбору и анализу требований учат в вузе, любой разработчик это умеет.
Пользователь не хочет никакой системы получить. И уж тем более, ему плевать на блокчейн. Нужно не нафантазировать, что он хочет, а пойти и спросить у него и бережно записать.
Блокчейн нужен, если есть какая-то пользовательская история, которую невозможно сделать без блокчейна, но очень хочется. А не просто так от балды.
Пользовательская история — это запись требований в таком виде, чтобы каждому был очевиден буллшит в постановке задач. Чтобы уборщица посмотрела в бэклог и могла сказать: «так не бывает, так живые люди не делают». «Добавить блокчейн» — никому не нужен блокчейн. «Я, как начальник участка хочу видеть, кому нужно всыпать люлей за низкую производительность» — вот это по-нашему.
Вы про искусство. Я же профессионально работаю фронтенд-разработчиком. Каждый день по 8 часов в день последние несколько лет. В работе реально помогает. Я и на ejs писал и на ангуляре первом — это все не то. Перечислять отличия бессмысленно, потому что все то же самое можно было сделать и раньше. Просто не удобно. Больше кода, больше ошибок, сложнее отлаживать, больше всяких нюансов неочевидных.
Работал, да перестал. Нужно же всегда иметь актуальные данные. Всегда можно еще улучшить.
Svelte, как и Vue — это просто развлечения их создателей, форма искусства, оторванная от практики. Как искусство они очень хороши, их изучать — одно удовольствие.
React и Angular — реальные инновации, они полезны экономически. Это просто совсем другой уровень. Комьюнити и коммерческие проекты — очень разные. И авторы комьюнити фреймворков принципиально не могут посмотреть на крупные коммерческие базы кода, их просто туда никто не пустит смотреть. Если их, конечно, не наймут в одну из таких компаний. Гвидо ван Россум сделал питон, потом его наняли в Google и он смог наблюдать, как его язык используется на практике и сделал python3, который стал конфликтовать с 2.7.
Можете сколько угодно писать, что Svelte «такой же, и даже лучше», но в действительности, единственная причина его появление — автору было скучно. Завтра он найдет себе другое занятие и кончится весь Svelte.
Молча грести и превозмогать. Если будете жаловаться, просто потратите больше сил в данной ситуации (не все жалобы бесполезны).