В аутсорсерах не работал, знаю только понаслышке с собеседований.

Но в продуктовых компаниях работал:

G> а) Устаревшие технологии.

Нет. Скорее _работающие_ технологии. Делать ставку на технологию с непонятным будущим опасно.

G> б) Устойчивая орг структура.

Не думаю что отличается от других компаний.

G> в) Есть люди, сидящие чуть ли не десятилетиям.

Бывает.

G> г) Профессиональный рост затруднен из-за а), карьерный практически невозможен из-за б) и в).

Оба неверно.

G> д) Сильная бюрократизация.

Совсем нет.

G> е) Возможна непрофильная работа, но благодаря д) с нее можно съехать.

Не понял что имелось в виду.

G> ж) Ритм работы относительно расслабленный.

Совсем наоборот.

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

Как я говорил, д) не является характеристикой продуктовых контор, на мой взгляд.

H>А для разработчика в чём отличие?

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

Здравствуйте, 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 начал расспрашивать об экономике.

Здравствуйте, Gradient, Вы писали:

G>>> е) Возможна непрофильная работа, но благодаря д) с нее можно съехать.
K>>Не понял что имелось в виду.
G>Имелось в виду, что сидишь ты девелопишь, а тут оказывается что кучу разных вещей (например, доки писать) делать некому. И дальше ты или по доброте душевной впрягаешься в эти задачи, либо начинаешь мягко съезжать: мол, рад бы, да своей работы по горло, да не умею я доки писать и т.д. В результате работа падает на самого чуткого из команды, кто не отвертелся.

Где здесь "непрофильность"? Программист обязан уметь выражаться на непрограммистских диалектах. Для справки: анализ требований, выбор инструментария, разработка архитектуры, кодирование, тестирование и документация — это всё входит в "профиль" программиста. Различаются только акценты и практическая наработка по тем или иным вопросам. Не вижу ничего зазорного в том, чтобы написать документацию или заняться тестированием, если больше это сделать некому.

Здравствуйте, Gradient, Вы писали:

E>>Что мешает об этих буковках читать? Понимать что нового они привнесли, чем они облегчат разработку. И если там новые идеи, то стараться эти идеи попробовать перенести на существующие старые технологии.
G>Читать — ничто не мешает. Попробовать ручками на тестовом проекте — тоже. А вот облегчить жизнь на текущем проекте как правило труднее, ибо проект — творчество коллективное.

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

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

Правильный поступок начальника. TDD в общем случае — бредовая затея из цикла игры в Прогрессивные Методы вместо банального анализа, детализации и формализации требований. Не путать с тестированием.

G>В результате можешь только сам на своей лужайке что-то улучшать, а проект в целом остается болотом.

Что есть "болото"? То, где тебе что-то не нравится?

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

Задумайся о том, как ты аргументировал необходимость автобилдов.

G>Может это мне так везло, что в компаниях со своим продуктом никто не хочет/не умеет ставить процесс?

Нет, не только тебе. И причины тому вполне объективные. Сам по себе процесс — нуль без палочки, он вообще никому не нужен. Нужны те качества, которые привносит процесс, сиречь: ясность и предсказуемость. Если этого удаётся добиться без формального процесса, то он никому и не нужен.

G>Реально, если сравнивать компании, в каких из них наилучшим образом поставлен процесс разработки? В каких категориях компаний максимально эффективно прокачиваются технические скилы?

Ты не правильно подходишь к снаряду: тут от "категорий" компании ничего не зависит.

Здравствуйте, 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) Компания, не имеющая конкурентов.
А аутсорс или свой продукт значения не имеет.

DO>1) Компания, работающая в условиях жесткой конкуренции.
DO>2) Компания, не имеющая конкурентов.
DO>А аутсорс или свой продукт значения не имеет.

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

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

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

G>>> г) Профессиональный рост затруднен из-за а), карьерный практически невозможен из-за б) и в).
K>>Оба неверно.
G>>> д) Сильная бюрократизация.
K>>Совсем нет.

G>А можно поподробнее плз, с примерами?

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