G>1) В случае с аутсорсером мы имеем следующие характеристики: G> а) Быстрое освоение новых технологий.
Зависит от как себя продают, могут и на коболе сидеть. G> б) Ротация кадров. G> в) Относительно большая текучка.
Это одно и тоже. G> г) Как следствие б) и в) возможен профессиональный и карьерный рост.
Рост в кого? в псевдо-прожект менеджера? Больше там расти не в кого. Вы уверене, что это рост для программиста? G> д) Возможна непрофильная работа (что продали — то и делай).
Это проблема слабого менеджмента, и если в продуктах это оправдано, то в аутсорсе — не допустимо.
Нормальный аутсорсер, проще сбросит на суб подряд.
Если конечно, мы не перебиваемся а бы и чем хватаем что дают, а не что умеем делать. G> е) Бюрократия незначительна.
???? многие акрупные утсосреры имеют СММ5, много знаете продуктовых контор с СММ5? G> ж) Начальство бесчеловечно выжимает и прессует, была бы маржа.
А это по разному, зависит от конкретного начальства. Но ритм действительно более истеричный, но это из за коротких проектов. G> з) Устаревшее оборудование. Любое обновление необходимо жестко финансово обосновывать.
По моему, не зависит от типа компании, а от жлобства руководства.
+ Низкая зарплата.
+ Как правило весьма средний уровень команды (ну не нужны обычно в аутсорсе люди выше среднего)
+ (частенько) Не интересные проекты
G>2) В случае своего продукта не особо существенно, является ли продукт "коробкой" или же он разрабатывается под конкретного жирного заказчика. Характеристики:
А тут нужно разделять. Контора одного проекта это по сути не профильный отдел заказчика, где директор смог урвать больше денег.
Я коментирую как для контор делающих "коробку":
G> а) Устаревшие технологии.
Да. продукт движется и никто не будет менять технологии на ходу.
Но как правило делается куча пилотов, а там самые что не на есть новые технологии. G> б) Устойчивая орг структура. G> в) Есть люди, сидящие чуть ли не десятилетиям.
Да, текучка меньше.
Люди ценятся выше.
Иногда, собираются очень сильные команды.
G> г) Профессиональный рост затруднен из-за а), карьерный практически невозможен из-за б) и в).
Если профессиональный рост это список абревиатур, то да.
Но если речь идёт про разработку, то скорее наоборот Вы увидете как живёт продукт, какие подходы оказались жизнеспособны и прошли проверку временем, а что нет.
Это скорее рост в архитектора и пр.
Возможна смена специализации в продуктовую строну.
Карьерный рост зависит от роста компании. Да он более обдуманый.
В аутсорсе фраза: "прожектменеджером сделаем Васю, он единственный кто больше года тут работает" звучит часто. Тут вряд ли.
То есть если нужно просто запись в резюме, то аутсорс удобнее.
Прожект менеджеры бывают настоящими
G> д) Сильная бюрократизация.
Зависит скорее от размера, а не от профиля.
G> е) Возможна непрофильная работа, но благодаря д) с нее можно съехать.
Возможна и вполне оправдана.
Есть смысл обучать людей.
G> ж) Ритм работы относительно расслабленный.
Зависит от компании.
G> з) Оборудование может быть как очень старым, так и новым. При наличии бюджета обновления проходят долго из-за д), при отсутсвии бюджета — не проходят вообще.
По моему вы сравниваете мелкого аутсорсера и болото пишущее 20 лет автоматизацию под конкретного крупного заказчика...
Основное отличие состоит в том, является ли работодатель
1) аутсорсером
2) или клепает свой продукт
Остальные виды ИМХО не столь существенны.
1) В случае с аутсорсером мы имеем следующие характеристики:
а) Быстрое освоение новых технологий.
б) Ротация кадров.
в) Относительно большая текучка.
г) Как следствие б) и в) возможен профессиональный и карьерный рост.
д) Возможна непрофильная работа (что продали — то и делай).
е) Бюрократия незначительна.
ж) Начальство бесчеловечно выжимает и прессует, была бы маржа.
з) Устаревшее оборудование. Любое обновление необходимо жестко финансово обосновывать.
2) В случае своего продукта не особо существенно, является ли продукт "коробкой" или же он разрабатывается под конкретного жирного заказчика. Характеристики:
а) Устаревшие технологии.
б) Устойчивая орг структура.
в) Есть люди, сидящие чуть ли не десятилетиям.
г) Профессиональный рост затруднен из-за а), карьерный практически невозможен из-за б) и в).
д) Сильная бюрократизация.
е) Возможна непрофильная работа, но благодаря д) с нее можно съехать.
ж) Ритм работы относительно расслабленный.
з) Оборудование может быть как очень старым, так и новым. При наличии бюджета обновления проходят долго из-за д), при отсутсвии бюджета — не проходят вообще.
Какие еще есть существенно отличающиеся для сотрудника виды компаний?
-----
Любимая фраза физика-теоретика: "Вот видите, мы ошиблись всего лишь на порядок".
Здравствуйте, Gradient, Вы писали:
E>>Что мешает об этих буковках читать? Понимать что нового они привнесли, чем они облегчат разработку. И если там новые идеи, то стараться эти идеи попробовать перенести на существующие старые технологии. G>Читать — ничто не мешает. Попробовать ручками на тестовом проекте — тоже. А вот облегчить жизнь на текущем проекте как правило труднее, ибо проект — творчество коллективное.
Угу, и не все будут считать твои идеи облегчением. И иной раз у них окажутся вполне веские доводы.
G>Например, знаешь про буковки TDD. Коллегам показал. Половине коллег понравилось, половине — нет, начальник воздержался.
Правильный поступок начальника. TDD в общем случае — бредовая затея из цикла игры в Прогрессивные Методы вместо банального анализа, детализации и формализации требований. Не путать с тестированием.
G>В результате можешь только сам на своей лужайке что-то улучшать, а проект в целом остается болотом.
Что есть "болото"? То, где тебе что-то не нравится?
G>Или обсудили что есть такая штука как автобилды. Ну да, есть, но без поддержки руководства, которое очень хорошее, да вот знания у которого несколько устарели — никакого движения. Ну не буду же я локально виртуалку с билдсервером только для себя поднимать
Задумайся о том, как ты аргументировал необходимость автобилдов.
G>Может это мне так везло, что в компаниях со своим продуктом никто не хочет/не умеет ставить процесс?
Нет, не только тебе. И причины тому вполне объективные. Сам по себе процесс — нуль без палочки, он вообще никому не нужен. Нужны те качества, которые привносит процесс, сиречь: ясность и предсказуемость. Если этого удаётся добиться без формального процесса, то он никому и не нужен.
G>Реально, если сравнивать компании, в каких из них наилучшим образом поставлен процесс разработки? В каких категориях компаний максимально эффективно прокачиваются технические скилы?
Ты не правильно подходишь к снаряду: тут от "категорий" компании ничего не зависит.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Gradient, Вы писали:
G>>> е) Возможна непрофильная работа, но благодаря д) с нее можно съехать. K>>Не понял что имелось в виду. G>Имелось в виду, что сидишь ты девелопишь, а тут оказывается что кучу разных вещей (например, доки писать) делать некому. И дальше ты или по доброте душевной впрягаешься в эти задачи, либо начинаешь мягко съезжать: мол, рад бы, да своей работы по горло, да не умею я доки писать и т.д. В результате работа падает на самого чуткого из команды, кто не отвертелся.
Где здесь "непрофильность"? Программист обязан уметь выражаться на непрограммистских диалектах. Для справки: анализ требований, выбор инструментария, разработка архитектуры, кодирование, тестирование и документация — это всё входит в "профиль" программиста. Различаются только акценты и практическая наработка по тем или иным вопросам. Не вижу ничего зазорного в том, чтобы написать документацию или заняться тестированием, если больше это сделать некому.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Gradient, Вы писали:
G>Например, знаешь про буковки TDD. Коллегам показал. Половине коллег понравилось, половине — нет, начальник воздержался. В результате можешь только сам на своей лужайке что-то улучшать, а проект в целом остается болотом.
Пиши в нормальном стиле, если есть возможность тестировать без срыва сроков — пиши тесты. Нет времени на тесты — пиши так, чтобы эти тесты была возможность написать — вот тебе и TDD. На собеседованиях говори — остальные не применяют, а я применяю — это больший плюс тебе, чем если б ты применял из под палки.
G>Или обсудили что есть такая штука как автобилды. Ну да, есть, но без поддержки руководства, которое очень хорошее, да вот знания у которого несколько устарели — никакого движения. Ну не буду же я локально виртуалку с билдсервером только для себя поднимать
Во первых, от того, что в компании применяются автобилды проку в плане развития никакого — это просто облегчает жизнь и ускоряет разработку. Если же выпросил у начальства комп и первым настроил автобилд — сможешь наоборот гордиться.
Но автобилды это ладно, тут если ну никак не хотят отдельный комп выделить, особо ничего не сделать, только если ночами гонять под виртуалкой. Знаю некоторые организации, сотрудники которых не могут системы контроля версий внедрить — вот тут уже на начальство пенять нельзя, это в силах рядового разработчика поставить себе сервер.
Проблема в том, что инициатива всегда должна идти снизу, ответственность за проект, за сроки, всегда больше всего будет лежать на рядовом разработчике, но ни в коем случае не на начальнике. Тот, кто занимается организационными вопросами уже давно не технический специалист, инициатива от начальства крайне маловероятна. В большинстве случаев за проблемы в проекте начальнику скажут что-то устно, а работникам придется овертаймить, им откажут в повышении, не повысят зарплату из-за низкой эффективности и т.д. Потому нет вариантов — надо сидеть, и пробивать необходимые проекту решения снизу. Личным примером, а не насильно. Не теряешь вообще ничего на самом деле, если овертаймить приходится в любом случае — проще при этих овертаймах разобраться с причинами, их пофиксить. Если же овертаймов нет, то просто параллельно основной работе делать то, что никто больше сделать не может.
По моему привлекательность работадателя зависит от
1 Бюджета проекта
2 Критичности проекта для бизнеса
3 Личных и проффесиональных качеств проектной команды
4 Отношения руководства к проекту
Оптимальные сочетания этих пунктов можно встретить вне зависимости от области деятельности компании
аутсорсер , разработчик своего продукта или внутренний ИТ отдел.
Лично я очень скептически отношусь с бюджетным конторам. Скорее всего болото, быстро портящее даже нормальных людей, которые туда случайно попадают. Примерно как стартапы без цели заработать
G>Основное отличие состоит в том, является ли работодатель G>1) аутсорсером G>2) или клепает свой продукт
Не верные названия. Правильно так:
1) Компания, работающая в условиях жесткой конкуренции.
2) Компания, не имеющая конкурентов.
А аутсорс или свой продукт значения не имеет.
Здравствуйте, Gradient, Вы писали:
G>1) В случае с аутсорсером мы имеем следующие характеристики: G> а) Быстрое освоение новых технологий. G> б) Ротация кадров. G> в) Относительно большая текучка. G> г) Как следствие б) и в) возможен профессиональный и карьерный рост.
С моей точки зрения карьерный рост характеризуется тем, что ты имеешь больше возможностей на то, чтобы влиять на проект. Увы, в аутсорсинге скорее наоборот, управленец занимается в основном тем, что пишет отчеты, заполняет вики, наизусть помнит требования. То есть видим имитацию карьерного роста, когда вместо непосредственно работы занимаешься тем, что стоишь с палкой и следишь, чтобы работали другие.
С точки зрения профессионального роста — тоже затруднительно. Обычно на аутсорс отдается все самое гадкое, часто это саппорт, часто на старых технологиях. Иногда ставится задача переписать на новых, но ... типичные задачи будут тривиальные, критические части будут делать скорее всего на стороне заказчика, именно заказчик будет часто диктовать и архитектуру, и технологии, и на этих технологиях будешь в основном грязную работу выполнять — какой профессиональный рост? Но да, надсмотрщиком стать в аутсорсинговых конторах достаточно просто, вот только не у всех есть такое жедание.
G>2) В случае своего продукта не особо существенно, является ли продукт "коробкой" или же он разрабатывается под конкретного жирного заказчика. Характеристики: 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.: Винодельческие провинции — это есть рулез!
elmal пишет: > > С моей точки зрения карьерный рост характеризуется тем, что ты имеешь > больше возможностей на то, чтобы влиять на проект.
Спорно. Допустим Program Manager (это больше чем Project Manager) не так
уж стремится "влиять" на те проекты, которые он курирует — ему важнее
найти людей, которые необходимость такого влияния сведут к минимуму. И
при движении вверх по карьерной лестнице тенденция сохраняется.
Это просто другая работа, _карьерный_ же рост собственно _разработчика_
в любом случае, независимо от типа компании, заканчивается очень быстро.
Потолок здесь крайне низок, в отличии от роста профессионального, где
предела совершенствованию практически нет.
> Увы, в аутсорсинге > скорее наоборот, управленец занимается в основном тем, что пишет отчеты, > заполняет вики, наизусть помнит требования.
В аутсорсинге, как правило, каждый занимается своим делом — разработчик
разрабатывает, управленец управляет. Требованиями занимаются обычно
аналитики.
> С точки зрения профессионального роста — тоже затруднительно. Обычно на > аутсорс отдается все самое гадкое, часто это саппорт, часто на старых > технологиях.
"Обычно" — это выборка из скольких проектов, в которых вы лично
участвовали? Мой опыт работы в аутсорсере это наблюдение не
подтверждает, шлака там есть примерно процентов 20-25 но никак не 100.
> именно заказчик будет часто диктовать и архитектуру, > и технологии, и на этих технологиях будешь в основном грязную работу > выполнять — какой профессиональный рост?
Да, высокоуровневые технические решения придётся защищать перед
заказчиком, в т.ч. возможно бодаясь с его архитекторами. В этой борьбе
вполне реально проиграть и тогда придётся принять "их" решения. Про
"грязную" работу не вполне ясно что имелось в виду — кодирование что ли?
Так его так и так делать надо, от вида компании это не зависит.
> G> г) Профессиональный рост затруднен из-за а), карьерный практически > невозможен из-за б) и в). > Имхо возможностей для профессионального роста больше тем, что если ты > делаешь большой вклад в проект, это окажется заметно. Также, так как > проект долгосрочный, то выгода от того, что ты будешь выполнять работу > хорошо достанется тебе, а не тем, кто будет позже тебя, снова больше > шансов что тебя заметят
"Старик Державин нас заметил, и, в гроб сходя, благословил"
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Gradient, Вы писали:
E>С моей точки зрения карьерный рост характеризуется тем, что ты имеешь больше возможностей на то, чтобы влиять на проект. Увы, в аутсорсинге скорее наоборот, управленец занимается в основном тем, что пишет отчеты, заполняет вики, наизусть помнит требования. То есть видим имитацию карьерного роста, когда вместо непосредственно работы занимаешься тем, что стоишь с палкой и следишь, чтобы работали другие.
ПМ, выживший в аутсорсе, когда его тр... прессуют заказчики, свое начальство да еще и девелоперы вечно недовольны — выживет где угодно
А на инхаус проэктах зачастую даже требований нет, которые можно было бы помнить наизусть
E>С точки зрения профессионального роста — тоже затруднительно. Обычно на аутсорс отдается все самое гадкое, часто это саппорт, часто на старых технологиях. Иногда ставится задача переписать на новых, но ... типичные задачи будут тривиальные, критические части будут делать скорее всего на стороне заказчика, именно заказчик будет часто диктовать и архитектуру, и технологии, и на этих технологиях будешь в основном грязную работу выполнять — какой профессиональный рост?
Гадкое — факт. Но именно на 10-й попытке скрестить ежа и ужа приходит просветление, и, во-первых, ты имеешь представление о разных видах ежей, а во-вторых способен сходу врубиться во что угодно. Это, конечно же, относится к отечественным заказчикам. И архитектуру они, кстати, не диктуют, ибо не знаю что это А если заказчик импортного разлива — да, надо работать по его процессам под четким надзором. Но это имхо даже плюс.
Но у аутсорсера есть имхо очень серьезный минус: от гонки продали-сделали-забыли-продали, в сжатые сроки и неважным качеством, быстро устанешь.
E>Имхо возможностей для профессионального роста больше тем, что если ты делаешь большой вклад в проект, это окажется заметно. Также, так как проект долгосрочный, то выгода от того, что ты будешь выполнять работу хорошо достанется тебе, а не тем, кто будет позже тебя, снова больше шансов что тебя заметят, снова больше шансов что тебе поручат более квалифицированную работу, снова больше шансов того, что у тебя появится шанс вырасти. На деле, квалификация определяется не тем, что ты типа на новейших технологиях лабаешь, а тем, как ты умеешь использовать то, что есть.
А вот у меня (да и не только) есть страх оказаться не у дел через n лет. Да, на текущем проекте ты можешь стать просто незаменимым, корону на голову наденешь. Но что будет если через эти n лет обнаружишь, что в мире появилось много трехбуквенных сокращений, о которых ты не слышал? я не хочу сказать что новые буковки это хорошо или плохо, хочу сказать что их незнание при поиске работы существенно сужает область поиска.
E> Увы, часто слишком молодые руководители этого не понимают, так как из джуниора сразу стали руководить, так и не научившись программировать. Квалификация как не была высокой, а как в куроводители подались, так стала еще ниже, так как мир не стоит на месте.
Увы, это извечная проблема — когда из посредственного работника становится плохой руководитель.
-----
Любимая фраза физика-теоретика: "Вот видите, мы ошиблись всего лишь на порядок".
Здравствуйте, Gradient, Вы писали:
G>А вот у меня (да и не только) есть страх оказаться не у дел через n лет. Да, на текущем проекте ты можешь стать просто незаменимым, корону на голову наденешь. Но что будет если через эти n лет обнаружишь, что в мире появилось много трехбуквенных сокращений, о которых ты не слышал? я не хочу сказать что новые буковки это хорошо или плохо, хочу сказать что их незнание при поиске работы существенно сужает область поиска.
Что мешает об этих буковках читать? Понимать что нового они привнесли, чем они облегчат разработку. И если там новые идеи, то стараться эти идеи попробовать перенести на существующие старые технологии. Прикол в том, что на старых технологиях, как правило, программировать наоборот сложнее, все новые технологии разработку наоборот упрощают. Соответственно если ты умеешь просто писать поверх старых технологий — это означает, что ты создаешь новые технологии, и не пользуешь существующие (это как раз не изобретение велосипедов, а необходимая вещь — написание высокоуровневых абстракций). Область поиска да, сужает, сквозь HR часто пройти будет проблематично. Но, те конторы, которые возьмут и которых это не смутит, которые будут оценивать умение программировать, а не знание буковок — это будут лучшие конторы .
Здравствуйте, Gradient, Вы писали:
G>Здравствуйте, elmal, Вы писали:
E>>Здравствуйте, Gradient, Вы писали:
E>> Увы, часто слишком молодые руководители этого не понимают, так как из джуниора сразу стали руководить, так и не научившись программировать. Квалификация как не была высокой, а как в куроводители подались, так стала еще ниже, так как мир не стоит на месте.
G>Увы, это извечная проблема — когда из посредственного работника становится плохой руководитель.
Да, наверное, даже не проблема, а намеренно культивируемое, особенно в корпорациях, явление под названием "карьеризм", редко совместимое с инженерной работой.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Gradient, Вы писали:
E>Что мешает об этих буковках читать? Понимать что нового они привнесли, чем они облегчат разработку. И если там новые идеи, то стараться эти идеи попробовать перенести на существующие старые технологии.
Читать — ничто не мешает. Попробовать ручками на тестовом проекте — тоже. А вот облегчить жизнь на текущем проекте как правило труднее, ибо проект — творчество коллективное.
Например, знаешь про буковки TDD. Коллегам показал. Половине коллег понравилось, половине — нет, начальник воздержался. В результате можешь только сам на своей лужайке что-то улучшать, а проект в целом остается болотом.
Или обсудили что есть такая штука как автобилды. Ну да, есть, но без поддержки руководства, которое очень хорошее, да вот знания у которого несколько устарели — никакого движения. Ну не буду же я локально виртуалку с билдсервером только для себя поднимать
Может это мне так везло, что в компаниях со своим продуктом никто не хочет/не умеет ставить процесс?
Реально, если сравнивать компании, в каких из них наилучшим образом поставлен процесс разработки? В каких категориях компаний максимально эффективно прокачиваются технические скилы?
-----
Любимая фраза физика-теоретика: "Вот видите, мы ошиблись всего лишь на порядок".
Здравствуйте, Gradient, Вы писали:
G>Может это мне так везло, что в компаниях со своим продуктом никто не хочет/не умеет ставить процесс?
Это зависит от того кто начинал строить компанию.
Если программисты, то процесс есть.
Но зачастую начинают люди которые шарят в предметной области и немного программировать (туда же те кто вырос из мелких шароварок, у них просто нет опыта разработки), и разрабатывается продукт по принципу "не стреляйте в программиста он играет как умеет". Со временем это выровняется или продукт станет просто разваливаться. Появятся процессы, усилится команда, но для этого нужно время. Продуктовые компании растут медленее.
G>Реально, если сравнивать компании, в каких из них наилучшим образом поставлен процесс разработки?
А что такое поставлен процесс разработки? их много и сложно сказать где он хороший где нет.
Продуктовые компании строят свой, он как правило кривой, но он вырощеный. И всё имеет свое объяснение, пускай и типа: мы пробовали планировать, но не выходит — по этому и бросили.
Аутсорсеры пытаются прекрытся какой то сертифицированой методологией или прогибаются под заказчика.
Им процесс вообще нужен как зайцу пятая нога, им скорее учёт нужен. Процесс стоит денег и не окупается на мелких проектах.
Если за процесс готов платить заказчик, то какой то процесс есть. А если всё мелкие фиксед косты, то как правило весь процесс это попытка получить отчёт по минутам (утрирую
G>В каких категориях компаний максимально эффективно прокачиваются технические скилы?
А что такое технические скилы?
Если список технологий и куча сертификатов, то идите в тренеры.
Если просто передовые технологии, то в тех компаниях в которых они используются. И тут не важно какого компания типа.
В любом случае вы не сможете быть всё время на острее технологии (только самоучение). Если идёт проект в течении года и в это время выходит новый фреймворк (компилер и тд.) то никто не будет переходить на него в середине разработки. То есть на пол года уже отстали Если речь идёт про проекты 1-2 месяца, то конечно можно пользовать самое новьё, но это только для строчки в резюме. Но при этом у вас не будет опыта использования той же технологии в чём то крупном.
Здравствуйте, sined, Вы писали:
S>По моему привлекательность работадателя зависит от
S>1 Бюджета проекта S>2 Критичности проекта для бизнеса S>3 Личных и проффесиональных качеств проектной команды S>4 Отношения руководства к проекту
Здравствуйте, eaa, Вы писали:
eaa>работодатель != проект
Трудно оценить компанию работодателя в целом , программист же работает в конкретном проекте , группе проектов.
Это особенно критично в аутсорсинге. В таких компаниях условия в разных проектах могут отличатся как небо и земля.
На форуме уже не раз про одну и ту же аутсорсинговую компанию разные люди отзываются совершенно противоположно.
Да я и сам работаю в аутсорсере среднего размера и вижу что от конкреного проекта очень очень много зависит.
Здравствуйте, sined, Вы писали:
S>Здравствуйте, eaa, Вы писали:
eaa>>работодатель != проект
S> Трудно оценить компанию работодателя в целом , программист же работает в конкретном проекте , группе проектов. S>Это особенно критично в аутсорсинге. В таких компаниях условия в разных проектах могут отличатся как небо и земля. S>На форуме уже не раз про одну и ту же аутсорсинговую компанию разные люди отзываются совершенно противоположно. S>Да я и сам работаю в аутсорсере среднего размера и вижу что от конкреного проекта очень очень много зависит.
Ну если компания аутсорсер (не аутстаффер!), то после оканчания проекта попадаешь в другой.
Да и в рамках одного проекта не понятно как влияют описаные вам факторы, на условия работы:
S>1 Бюджета проекта
девелоперам с этого не холодно не жарко.
S>2 Критичности проекта для бизнеса
это хорошо или плохо? это значит что что будут стоять над душой? ограничивать совбоду? устраивать бюрократию? давать больше премий?
по моему просто зависит от руководства. пункт 4.
S>3 Личных и проффесиональных качеств проектной команды
это да.
S>4 Отношения руководства к проекту
это да.
Вот и вышло, что всё определилось людьми с которыми работать, а не как не проектом.
Gradient пишет: > > Реально, если сравнивать компании, в каких из них наилучшим образом > поставлен процесс разработки?
Аутсорсер, у которого не поставлены процессы, быстро окажется out of
business, это для аутсорса элементарно вопрос выживания.
Да и аудит на CMM5 просто так не пройдёшь, надо реально что-то
показывать соответствующее.
Продуктовая компания (ИТ-отдел несофтверной компании) до поры до времени
может на процессы забивать. А может и нет.
> В каких категориях компаний максимально > эффективно прокачиваются технические скилы?
Это скорее от конкретных проектов зависит, а не от компаний.
Здравствуйте, eaa, Вы писали:
eaa>Ну если компания аутсорсер (не аутстаффер!), то после оканчания проекта попадаешь в другой.
Ой не всегда , не знаю уж как в других аутсорсерах . Но у нас например многие проекты не кончаются.
И в принципе можно и лет десять в одном проекте проработать. Вообщем я бы сказал шансы фифти — фифти , что проект будет краткосрочный.
eaa>Да и в рамках одного проекта не понятно как влияют описаные вам факторы, на условия работы:
S>>1 Бюджета проекта eaa>девелоперам с этого не холодно не жарко.
Не скажи . Это только так руководство любит декларировать что мол де все равны и по делам их да воздастся. Если проект имеет хороший бюджет руководство ой как пристально за ним следит , что соответсвенно сказывается на отношении к участникам проекта в виде премий , поощрений , своевременного увеличения зарплаты .
S>>2 Критичности проекта для бизнеса eaa>это хорошо или плохо? это значит что что будут стоять над душой? ограничивать совбоду? устраивать бюрократию? давать больше премий? eaa>по моему просто зависит от руководства. пункт 4.
Это значит что профессионализм в таком проекте не блажь а насущная необходимость. То что девелоперы ваяли по принципу и так сойдет здесь не прокатит. Соответсвенно деловые качества тут сильно ценятся.
S>>3 Личных и проффесиональных качеств проектной команды eaa>это да.
S>>4 Отношения руководства к проекту eaa>это да.
eaa>Вот и вышло, что всё определилось людьми с которыми работать, а не как не проектом.
Очень часто бывает что люди просто замечательные, а вот деньги никакие совсем
Здравствуйте, sined, Вы писали:
eaa>>Ну если компания аутсорсер (не аутстаффер!), то после оканчания проекта попадаешь в другой.
S>Ой не всегда , не знаю уж как в других аутсорсерах . Но у нас например многие проекты не кончаются. S>И в принципе можно и лет десять в одном проекте проработать. Вообщем я бы сказал шансы фифти — фифти , что проект будет краткосрочный.
Проект который не заканчивается? Ну это совсем плохо...
Хотя тут, скорее, просто используется слово проект не верно.
Проект имеет чёткие сроки. Вас же видимо просто продали по головам. это аутстаффинг.
S>>>1 Бюджета проекта eaa>>девелоперам с этого не холодно не жарко.
S> Не скажи . Это только так руководство любит декларировать что мол де все равны и по делам их да воздастся. Если проект имеет хороший бюджет руководство ой как пристально за ним следит , что соответсвенно сказывается на отношении к участникам проекта в виде премий , поощрений , своевременного увеличения зарплаты .
Это отношение руководства. Но никак не бюджет проекта. Бюджет это сколько денег будет освоено на разработку (и туда входит: зарплаты, оренды, командировки, консультации). Бюджет корелирует с размером проекта, но ни как не с зарплатами внутри.
S>>>2 Критичности проекта для бизнеса eaa>>это хорошо или плохо? это значит что что будут стоять над душой? ограничивать совбоду? устраивать бюрократию? давать больше премий? eaa>>по моему просто зависит от руководства. пункт 4.
S> Это значит что профессионализм в таком проекте не блажь а насущная необходимость. То что девелоперы ваяли по принципу и так сойдет здесь не прокатит. Соответсвенно деловые качества тут сильно ценятся.
тут есть несколько слов которые нужно прояснить: критичность для бизнеса, профессионализм, деловые качества.
а то много не однозначностей.
критичность для бизнеса (то есть в случае неудачи. бизнес может перестать существовать) — это или стартап или "контора одного проекта" или неадекватный менеджмент.
первый случай, на любителя. Можно ввязываться, но там обычно ничего не дают, там всё потом.
остальные — как по мне, не стоит и рассматривать.
Если проект важный, то на нём нужно получить прогнозируемый результат. Косо-криво (с минимальным приемлимым качеством), но во время. И команда должна идти до конца, а не быть сильной.
То есть, то что Васе дали кредит на квартиру в этой фирме, это стоит больше, чем то что Петя програмирует лучше Васи. Можно пообещать большой бонус, но это дорого
А вот тотальный контроль вероятнее всего будет. И загнаная команда вероятнее всего будет (каждый уровень будет страховаться и резать сроки).
Так что я не уверен, что кретичность для бизнеса это плюс.
S>Очень часто бывает что люди просто замечательные, а вот деньги никакие совсем
А как вы узнали про этих замечательных людей? Если не подошла зарплата, то знакомится с кем то кроме замечательного ХР — не нужно.
В аутсорсерах не работал, знаю только понаслышке с собеседований.
Но в продуктовых компаниях работал:
G> а) Устаревшие технологии.
Нет. Скорее _работающие_ технологии. Делать ставку на технологию с непонятным будущим опасно.
G> б) Устойчивая орг структура.
Не думаю что отличается от других компаний.
G> в) Есть люди, сидящие чуть ли не десятилетиям.
Бывает.
G> г) Профессиональный рост затруднен из-за а), карьерный практически невозможен из-за б) и в).
Оба неверно.
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>>> г) Профессиональный рост затруднен из-за а), карьерный практически невозможен из-за б) и в). K>>Оба неверно. G>>> д) Сильная бюрократизация. K>>Совсем нет.
G>А можно поподробнее плз, с примерами?
Пример — мой профайл на LinkedIn. Все конторы, начиная с двухтысячного — продуктовые. Ничего из вышеперечисленного там не наблюдал.
Вы увидете как живёт продукт, какие подходы оказались жизнеспособны и прошли проверку временем, а что нет. 
