В аутсорсерах не работал, знаю только понаслышке с собеседований.
Но в продуктовых компаниях работал:
G> а) Устаревшие технологии.
Нет. Скорее _работающие_ технологии. Делать ставку на технологию с непонятным будущим опасно.
G> б) Устойчивая орг структура.
Не думаю что отличается от других компаний.
G> в) Есть люди, сидящие чуть ли не десятилетиям.
Бывает.
G> г) Профессиональный рост затруднен из-за а), карьерный практически невозможен из-за б) и в).
Оба неверно.
G> д) Сильная бюрократизация.
Совсем нет.
G> е) Возможна непрофильная работа, но благодаря д) с нее можно съехать.
Не понял что имелось в виду.
G> ж) Ритм работы относительно расслабленный.
Совсем наоборот.
G> з) Оборудование может быть как очень старым, так и новым. При наличии бюджета обновления проходят долго из-за д), при отсутсвии бюджета — не проходят вообще.
Как я говорил, д) не является характеристикой продуктовых контор, на мой взгляд.
Лично я очень скептически отношусь с бюджетным конторам. Скорее всего болото, быстро портящее даже нормальных людей, которые туда случайно попадают. Примерно как стартапы без цели заработать
Здравствуйте, kosmik, Вы писали:
G>> е) Возможна непрофильная работа, но благодаря д) с нее можно съехать. K>Не понял что имелось в виду.
Имелось в виду, что сидишь ты девелопишь, а тут оказывается что кучу разных вещей (например, доки писать) делать некому. И дальше ты или по доброте душевной впрягаешься в эти задачи, либо начинаешь мягко съезжать: мол, рад бы, да своей работы по горло, да не умею я доки писать и т.д. В результате работа падает на самого чуткого из команды, кто не отвертелся.
G>> г) Профессиональный рост затруднен из-за а), карьерный практически невозможен из-за б) и в). K>Оба неверно. G>> д) Сильная бюрократизация. K>Совсем нет.
А можно поподробнее плз, с примерами?
-----
Любимая фраза физика-теоретика: "Вот видите, мы ошиблись всего лишь на порядок".
Здравствуйте, Gradient, Вы писали:
G>Основное отличие состоит в том, является ли работодатель G>1) аутсорсером G>2) или клепает свой продукт
Ошибка. "Свой" продукт запросто может быть продан компанией на сторону и не факт, что вместе с разработчиками, тогда как сторонний заказ может превратиться в основной, который будут долго и нудно разрабатывать, перерабатывать, и т.п.
G>Остальные виды ИМХО не столь существенны.
"Остальных" видов тьма-тьмущая. У каждой компании свои побрякушки. В смысле отношения к работникам в том числе.
G>1) В случае с аутсорсером мы имеем следующие характеристики: G> а) Быстрое освоение новых технологий.
В аутсорсинговых компаниях особо одарённые специалисты работают? Или атмосфера специфическая, способствующая быстрому освоению? Это для меня новость.
Так что не "быстрое освоение", а "возможность встрять в работу над заказом, где заказчик потребовал новых технологий". Однако, по секрету скажу тебе, что заказчик может потребовать VB6 или ASP (не-.Net).
G> б) Ротация кадров.
Не обязательно. Зависит от ценности скиллов данного кадра.
G> в) Относительно большая текучка.
Это прямо зависит от руководства. Текучка бывает и на "своих" продуктах компании. Это может быть даже сознательно проводимой политикой руководства.
G> г) Как следствие б) и в) возможен профессиональный и карьерный рост.
Или так и будут кидать с одного VB6-проекта на другой такой же. Для разнообразия — VBA/Word2003.
G> д) Возможна непрофильная работа (что продали — то и делай).
Где? В аутсорсе? Ты эти сказки про "людей, как ресурсы" меньше слушай, а если слушаешь, то хоть на ус мотай. Дешевле найти нового сотрудника или заказ по профилю имеющихся, чем специально совать людей на непрофильную работу.
G> е) Бюрократия незначительна.
Щаз! Пересогласовывать требования с заказчиком пробовал когда-нибудь?
G> ж) Начальство бесчеловечно выжимает и прессует, была бы маржа.
Не надо обобщать, ладно? Это зависит от начальства и сотрудников.
G> з) Устаревшее оборудование. Любое обновление необходимо жестко финансово обосновывать.
Волшебное слово "медленно работает" действует, как правило, магически. Подкреплённое соответствующими бумагами, подчас, сногсшибательно. При условии, что действительно медленно, а не кажется таковым. А "устаревшее" в смысле "не топовое" — это не аргумент.
G>2) В случае своего продукта не особо существенно, является ли продукт "коробкой" или же он разрабатывается под конкретного жирного заказчика. Характеристики: G> а) Устаревшие технологии.
Чушь невероятная, даже комментировать не хочу.
G> б) Устойчивая орг структура.
AFAIK, Intel практикует матричную организацию. Куда уж владелистей по отношению к своему продукту, а вот так вот.
G> в) Есть люди, сидящие чуть ли не десятилетиям.
Подозреваю, что ровно то же самое будет и в аутсорсинговых компаниях, когда аутсорсинг доживёт до возраста десятилетий.
G> г) Профессиональный рост затруднен из-за а), карьерный практически невозможен из-за б) и в).
Полная чепуха. Это всё сильно зависит от продукта.
G> д) Сильная бюрократизация.
С чего ты это взял? Бюрократия не бывает бесплатной, а компания, разрабатывающая свой продукт вовсе не заинтересована в том, чтобы внутренняя бюрократия задерживала его развитие. Из-за этого, кстати, могут плюнуть на сертификацию по всяким CMM, ISO и т.п., тогда как для аутсорсинговых компаний эта самая сертификация ни что иное, как возможность лишний раз пустить пыль в глаза заказчику.
G> е) Возможна непрофильная работа, но благодаря д) с нее можно съехать.
С непрофильной работы можно "съехать" благодаря здравому смыслу, а не д).
G> ж) Ритм работы относительно расслабленный.
Ну-ну. Слышал такое слово "релиз"? А "аврал"? А знаешь, что они могут быть синонимами в той самой продуктовой компании? И ровно обратная ситуация встречается в аутсорсе: проскакали сроки, ну и шут с ними, заказчик всё равно уже оплатил разработку.
G> з) Оборудование может быть как очень старым, так и новым. При наличии бюджета обновления проходят долго из-за д), при отсутсвии бюджета — не проходят вообще.
Иными словами, оно может быть любым. Только при наличии бюджета обновления задерживаются не из-за "бюрократии", коя есть зло воплощённое, а из-за того, что у техников полным-полно другой работы. А при отсутствии бюджета на обновление это не проходит и аутсорсинговой компании.
G>Какие еще есть существенно отличающиеся для сотрудника виды компаний?
Короче, чепуха от начала и до конца, не пугай народ. Различие только в жёсткости границ проектного бюджета: у аутсорсеров бюджеты, как правило, жёстче ограничены, чем у собственников продукта. Хотя это тоже по-всякому бывает. Бардак же и порядок могут быть и там, и там. То же самое относится к "профессиональному росту", "новым трёхбуквенным аббревиатурам" и прочей непрофильной работе над карьерой на старых компьютерах в бюрократических условиях, сертифицированных на CMM5. Пытаться предсказать эти характеристики по небольшому количеству формальных признаков — это даже не заблуждение, а праздная болтовня домохозяйки: "мужики бывают блондины и брюнеты, в джинсах или брюках, старые или молодые, но все они сволочи и хотят одного".
P.S.: O tempora, o mores... Шеридан задаёт детские вопросы по C++; Градиент лепит что-то несусветное про классификацию работодателей; осталось дождаться, чтобы VladD2 начал расспрашивать об экономике.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Gradient, Вы писали:
G>>> е) Возможна непрофильная работа, но благодаря д) с нее можно съехать. K>>Не понял что имелось в виду. G>Имелось в виду, что сидишь ты девелопишь, а тут оказывается что кучу разных вещей (например, доки писать) делать некому. И дальше ты или по доброте душевной впрягаешься в эти задачи, либо начинаешь мягко съезжать: мол, рад бы, да своей работы по горло, да не умею я доки писать и т.д. В результате работа падает на самого чуткого из команды, кто не отвертелся.
Где здесь "непрофильность"? Программист обязан уметь выражаться на непрограммистских диалектах. Для справки: анализ требований, выбор инструментария, разработка архитектуры, кодирование, тестирование и документация — это всё входит в "профиль" программиста. Различаются только акценты и практическая наработка по тем или иным вопросам. Не вижу ничего зазорного в том, чтобы написать документацию или заняться тестированием, если больше это сделать некому.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Gradient, Вы писали:
E>>Что мешает об этих буковках читать? Понимать что нового они привнесли, чем они облегчат разработку. И если там новые идеи, то стараться эти идеи попробовать перенести на существующие старые технологии. G>Читать — ничто не мешает. Попробовать ручками на тестовом проекте — тоже. А вот облегчить жизнь на текущем проекте как правило труднее, ибо проект — творчество коллективное.
Угу, и не все будут считать твои идеи облегчением. И иной раз у них окажутся вполне веские доводы.
G>Например, знаешь про буковки TDD. Коллегам показал. Половине коллег понравилось, половине — нет, начальник воздержался.
Правильный поступок начальника. TDD в общем случае — бредовая затея из цикла игры в Прогрессивные Методы вместо банального анализа, детализации и формализации требований. Не путать с тестированием.
G>В результате можешь только сам на своей лужайке что-то улучшать, а проект в целом остается болотом.
Что есть "болото"? То, где тебе что-то не нравится?
G>Или обсудили что есть такая штука как автобилды. Ну да, есть, но без поддержки руководства, которое очень хорошее, да вот знания у которого несколько устарели — никакого движения. Ну не буду же я локально виртуалку с билдсервером только для себя поднимать
Задумайся о том, как ты аргументировал необходимость автобилдов.
G>Может это мне так везло, что в компаниях со своим продуктом никто не хочет/не умеет ставить процесс?
Нет, не только тебе. И причины тому вполне объективные. Сам по себе процесс — нуль без палочки, он вообще никому не нужен. Нужны те качества, которые привносит процесс, сиречь: ясность и предсказуемость. Если этого удаётся добиться без формального процесса, то он никому и не нужен.
G>Реально, если сравнивать компании, в каких из них наилучшим образом поставлен процесс разработки? В каких категориях компаний максимально эффективно прокачиваются технические скилы?
Ты не правильно подходишь к снаряду: тут от "категорий" компании ничего не зависит.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, eaa, Вы писали:
eaa>Проект который не заканчивается? Ну это совсем плохо... eaa>Хотя тут, скорее, просто используется слово проект не верно. eaa>Проект имеет чёткие сроки. Вас же видимо просто продали по головам. это аутстаффинг.
Не хочу спорить о нюансах терминологии. Однако касательно разработки ПО можно заметить такой факт , что не очень часто можно встретить программное обеспечение которое сделали один раз и после этого оно будет существовать в неизменном виде . Обычно если такое ПО было удачным и восстребованным , то после первой версии следует вторая , третяя и так долгие долгие годы.
eaa>Это отношение руководства. Но никак не бюджет проекта. Бюджет это сколько денег будет освоено на разработку (и туда входит: зарплаты, оренды, командировки, консультации). Бюджет корелирует с размером проекта, но ни как не с зарплатами внутри.
А как же тогда определяются зарплаты внутри. Вот допустим есть внешний рейт аутсорсинга или есть приносящий некую прибыль программный продукт ,
неужели же зарплата девелопера с этим никак не коррелирует ?
eaa>тут есть несколько слов которые нужно прояснить: критичность для бизнеса, профессионализм, деловые качества. eaa>а то много не однозначностей. eaa>критичность для бизнеса (то есть в случае неудачи. бизнес может перестать существовать) — это или стартап или "контора одного проекта" или неадекватный менеджмент.
Ок, давайте под критичностью понимать цену ошибки в ПО. Согласитесь она очень разная. Обычно если цена ошибки высока то никто в здравом уме не будет рассуждать о привлечении людей только по принципу кто меньше попросит зарплату. Так же вопрос качества ПО в этом случае не будет задвигатся на последнее место.
S>>Очень часто бывает что люди просто замечательные, а вот деньги никакие совсем eaa>А как вы узнали про этих замечательных людей? Если не подошла зарплата, то знакомится с кем то кроме замечательного ХР — не нужно.
Всякое бывает. Условия меняются , кризисы случаются , а в начале 90 ых так и во все некуда податся было.
Здравствуйте, sined, Вы писали:
eaa>>Проект имеет чёткие сроки. Вас же видимо просто продали по головам. это аутстаффинг.
S> Не хочу спорить о нюансах терминологии. Однако касательно разработки ПО можно заметить такой факт , что не очень часто можно встретить программное обеспечение которое сделали один раз и после этого оно будет существовать в неизменном виде . Обычно если такое ПО было удачным и восстребованным , то после первой версии следует вторая , третяя и так долгие долгие годы.
Хм, разница во многом.
В том какую работу делает прожект менеджер. В том как собирается команда. Разное всё.
eaa>>Это отношение руководства. Но никак не бюджет проекта. Бюджет это сколько денег будет освоено на разработку (и туда входит: зарплаты, оренды, командировки, консультации). Бюджет корелирует с размером проекта, но ни как не с зарплатами внутри.
S> А как же тогда определяются зарплаты внутри. Вот допустим есть внешний рейт аутсорсинга или есть приносящий некую прибыль программный продукт , S> неужели же зарплата девелопера с этим никак не коррелирует ?
Зарплата внутри определяется, средним уровнем зарплат на рынке и тем на какие зарплаты удалось набрать людей.
Зарплата может быть выше рынка, но для этого должен быть высокий рейт и переборчивый заказчик.
Но если звучит слово рейт, то много платить не будут точно.
S> Ок, давайте под критичностью понимать цену ошибки в ПО. Согласитесь она очень разная. Обычно если цена ошибки высока то никто в здравом уме не будет рассуждать о привлечении людей только по принципу кто меньше попросит зарплату. Так же вопрос качества ПО в этом случае не будет задвигатся на последнее место.
Начнём с того, что ошибаются все. И команда хороших девеловперов это никак не спасает.
Кроме того нужно различать внутринее качество и внешнее.
Внутренее это красата кода и тд. Оно очень зависет от уровня разработчиков, но влияет в первую очередь на скорость/стоимость разаработки.
Внешнее это работа приложения по спецификации. На него влияют процессы, уровень тестеров, а девелоперы в последнюю очередь.
Так вот если мы говорим про цену ошибки, то тут важно именно внешнее качество.
Мне нравиться фраза Туполева: "Некрасивые самолеты не летают", но я видел как зреновейшие проекты внутри доводили до продакшен качества и наоборот.
Да править баги в красивом внутри ПО проще, но это всё упирается в деньги и время, но никак не в уровень девелоперов.
Мне довелось писать МЕДЕЦИНСКОЕ ПО командой из 6 джуниоров и ничего вышли на приемлемый уровень качества, да сорвали сроки, да получили овертаймы, но это ведь не имеет отношения к качеству.
кста я не согласен с определением "критичность проекта для бизнеса, как цена ошибки в результируещём ПО"
S>>>Очень часто бывает что люди просто замечательные, а вот деньги никакие совсем eaa>>А как вы узнали про этих замечательных людей? Если не подошла зарплата, то знакомится с кем то кроме замечательного ХР — не нужно. S> Всякое бывает. Условия меняются , кризисы случаются , а в начале 90 ых так и во все некуда податся было.
Ну если в какой то момент больше не платят, то значит эти деньги не "никакие совсем", а вполне приемлемые.
G>Основное отличие состоит в том, является ли работодатель G>1) аутсорсером G>2) или клепает свой продукт
Не верные названия. Правильно так:
1) Компания, работающая в условиях жесткой конкуренции.
2) Компания, не имеющая конкурентов.
А аутсорс или свой продукт значения не имеет.
G>Имелось в виду, что сидишь ты девелопишь, а тут оказывается что кучу разных вещей (например, доки писать) делать некому. И дальше ты или по доброте душевной впрягаешься в эти задачи, либо начинаешь мягко съезжать: мол, рад бы, да своей работы по горло, да не умею я доки писать и т.д. В результате работа падает на самого чуткого из команды, кто не отвертелся.
Девелопишь или код пишешь? Теоретически такое может быть, потому что, например, технического писателя нереально найти, а фигню брать не стоит. Только смысл давать это тому кто не хочет это делать или не умеет? Неужели в конторе других нет?
G>>> г) Профессиональный рост затруднен из-за а), карьерный практически невозможен из-за б) и в). K>>Оба неверно. G>>> д) Сильная бюрократизация. K>>Совсем нет.
G>А можно поподробнее плз, с примерами?
Пример — мой профайл на LinkedIn. Все конторы, начиная с двухтысячного — продуктовые. Ничего из вышеперечисленного там не наблюдал.
