Основное отличие состоит в том, является ли работодатель
1) аутсорсером
2) или клепает свой продукт
Остальные виды ИМХО не столь существенны.
1) В случае с аутсорсером мы имеем следующие характеристики:
а) Быстрое освоение новых технологий.
б) Ротация кадров.
в) Относительно большая текучка.
г) Как следствие б) и в) возможен профессиональный и карьерный рост.
д) Возможна непрофильная работа (что продали — то и делай).
е) Бюрократия незначительна.
ж) Начальство бесчеловечно выжимает и прессует, была бы маржа.
з) Устаревшее оборудование. Любое обновление необходимо жестко финансово обосновывать.
2) В случае своего продукта не особо существенно, является ли продукт "коробкой" или же он разрабатывается под конкретного жирного заказчика. Характеристики:
а) Устаревшие технологии.
б) Устойчивая орг структура.
в) Есть люди, сидящие чуть ли не десятилетиям.
г) Профессиональный рост затруднен из-за а), карьерный практически невозможен из-за б) и в).
д) Сильная бюрократизация.
е) Возможна непрофильная работа, но благодаря д) с нее можно съехать.
ж) Ритм работы относительно расслабленный.
з) Оборудование может быть как очень старым, так и новым. При наличии бюджета обновления проходят долго из-за д), при отсутсвии бюджета — не проходят вообще.
Какие еще есть существенно отличающиеся для сотрудника виды компаний?
-----
Любимая фраза физика-теоретика: "Вот видите, мы ошиблись всего лишь на порядок".
Здравствуйте, Gradient, Вы писали:
G>1) В случае с аутсорсером мы имеем следующие характеристики: G> а) Быстрое освоение новых технологий. G> б) Ротация кадров. G> в) Относительно большая текучка. G> г) Как следствие б) и в) возможен профессиональный и карьерный рост.
С моей точки зрения карьерный рост характеризуется тем, что ты имеешь больше возможностей на то, чтобы влиять на проект. Увы, в аутсорсинге скорее наоборот, управленец занимается в основном тем, что пишет отчеты, заполняет вики, наизусть помнит требования. То есть видим имитацию карьерного роста, когда вместо непосредственно работы занимаешься тем, что стоишь с палкой и следишь, чтобы работали другие.
С точки зрения профессионального роста — тоже затруднительно. Обычно на аутсорс отдается все самое гадкое, часто это саппорт, часто на старых технологиях. Иногда ставится задача переписать на новых, но ... типичные задачи будут тривиальные, критические части будут делать скорее всего на стороне заказчика, именно заказчик будет часто диктовать и архитектуру, и технологии, и на этих технологиях будешь в основном грязную работу выполнять — какой профессиональный рост? Но да, надсмотрщиком стать в аутсорсинговых конторах достаточно просто, вот только не у всех есть такое жедание.
G>2) В случае своего продукта не особо существенно, является ли продукт "коробкой" или же он разрабатывается под конкретного жирного заказчика. Характеристики: G> а) Устаревшие технологии. G> б) Устойчивая орг структура. G> в) Есть люди, сидящие чуть ли не десятилетиям. G> г) Профессиональный рост затруднен из-за а), карьерный практически невозможен из-за б) и в).
Имхо возможностей для профессионального роста больше тем, что если ты делаешь большой вклад в проект, это окажется заметно. Также, так как проект долгосрочный, то выгода от того, что ты будешь выполнять работу хорошо достанется тебе, а не тем, кто будет позже тебя, снова больше шансов что тебя заметят, снова больше шансов что тебе поручат более квалифицированную работу, снова больше шансов того, что у тебя появится шанс вырасти. На деле, квалификация определяется не тем, что ты типа на новейших технологиях лабаешь, а тем, как ты умеешь использовать то, что есть. Увы, часто слишком молодые руководители этого не понимают, так как из джуниора сразу стали руководить, так и не научившись программировать. Квалификация как не была высокой, а как в куроводители подались, так стала еще ниже, так как мир не стоит на месте.
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>Увы, это извечная проблема — когда из посредственного работника становится плохой руководитель.
Да, наверное, даже не проблема, а намеренно культивируемое, особенно в корпорациях, явление под названием "карьеризм", редко совместимое с инженерной работой.
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 Критичности проекта для бизнеса
3 Личных и проффесиональных качеств проектной команды
4 Отношения руководства к проекту
Оптимальные сочетания этих пунктов можно встретить вне зависимости от области деятельности компании
аутсорсер , разработчик своего продукта или внутренний ИТ отдел.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Gradient, Вы писали:
E>Что мешает об этих буковках читать? Понимать что нового они привнесли, чем они облегчат разработку. И если там новые идеи, то стараться эти идеи попробовать перенести на существующие старые технологии.
Читать — ничто не мешает. Попробовать ручками на тестовом проекте — тоже. А вот облегчить жизнь на текущем проекте как правило труднее, ибо проект — творчество коллективное.
Например, знаешь про буковки TDD. Коллегам показал. Половине коллег понравилось, половине — нет, начальник воздержался. В результате можешь только сам на своей лужайке что-то улучшать, а проект в целом остается болотом.
Или обсудили что есть такая штука как автобилды. Ну да, есть, но без поддержки руководства, которое очень хорошее, да вот знания у которого несколько устарели — никакого движения. Ну не буду же я локально виртуалку с билдсервером только для себя поднимать
Может это мне так везло, что в компаниях со своим продуктом никто не хочет/не умеет ставить процесс?
Реально, если сравнивать компании, в каких из них наилучшим образом поставлен процесс разработки? В каких категориях компаний максимально эффективно прокачиваются технические скилы?
-----
Любимая фраза физика-теоретика: "Вот видите, мы ошиблись всего лишь на порядок".
Здравствуйте, Gradient, Вы писали:
G>Может это мне так везло, что в компаниях со своим продуктом никто не хочет/не умеет ставить процесс?
Это зависит от того кто начинал строить компанию.
Если программисты, то процесс есть.
Но зачастую начинают люди которые шарят в предметной области и немного программировать (туда же те кто вырос из мелких шароварок, у них просто нет опыта разработки), и разрабатывается продукт по принципу "не стреляйте в программиста он играет как умеет". Со временем это выровняется или продукт станет просто разваливаться. Появятся процессы, усилится команда, но для этого нужно время. Продуктовые компании растут медленее.
G>Реально, если сравнивать компании, в каких из них наилучшим образом поставлен процесс разработки?
А что такое поставлен процесс разработки? их много и сложно сказать где он хороший где нет.
Продуктовые компании строят свой, он как правило кривой, но он вырощеный. И всё имеет свое объяснение, пускай и типа: мы пробовали планировать, но не выходит — по этому и бросили.
Аутсорсеры пытаются прекрытся какой то сертифицированой методологией или прогибаются под заказчика.
Им процесс вообще нужен как зайцу пятая нога, им скорее учёт нужен. Процесс стоит денег и не окупается на мелких проектах.
Если за процесс готов платить заказчик, то какой то процесс есть. А если всё мелкие фиксед косты, то как правило весь процесс это попытка получить отчёт по минутам (утрирую
G>В каких категориях компаний максимально эффективно прокачиваются технические скилы?
А что такое технические скилы?
Если список технологий и куча сертификатов, то идите в тренеры.
Если просто передовые технологии, то в тех компаниях в которых они используются. И тут не важно какого компания типа.
В любом случае вы не сможете быть всё время на острее технологии (только самоучение). Если идёт проект в течении года и в это время выходит новый фреймворк (компилер и тд.) то никто не будет переходить на него в середине разработки. То есть на пол года уже отстали Если речь идёт про проекты 1-2 месяца, то конечно можно пользовать самое новьё, но это только для строчки в резюме. Но при этом у вас не будет опыта использования той же технологии в чём то крупном.
Здравствуйте, sined, Вы писали:
S>По моему привлекательность работадателя зависит от
S>1 Бюджета проекта S>2 Критичности проекта для бизнеса S>3 Личных и проффесиональных качеств проектной команды S>4 Отношения руководства к проекту
Здравствуйте, Gradient, Вы писали:
G>Например, знаешь про буковки TDD. Коллегам показал. Половине коллег понравилось, половине — нет, начальник воздержался. В результате можешь только сам на своей лужайке что-то улучшать, а проект в целом остается болотом.
Пиши в нормальном стиле, если есть возможность тестировать без срыва сроков — пиши тесты. Нет времени на тесты — пиши так, чтобы эти тесты была возможность написать — вот тебе и TDD. На собеседованиях говори — остальные не применяют, а я применяю — это больший плюс тебе, чем если б ты применял из под палки.
G>Или обсудили что есть такая штука как автобилды. Ну да, есть, но без поддержки руководства, которое очень хорошее, да вот знания у которого несколько устарели — никакого движения. Ну не буду же я локально виртуалку с билдсервером только для себя поднимать
Во первых, от того, что в компании применяются автобилды проку в плане развития никакого — это просто облегчает жизнь и ускоряет разработку. Если же выпросил у начальства комп и первым настроил автобилд — сможешь наоборот гордиться.
Но автобилды это ладно, тут если ну никак не хотят отдельный комп выделить, особо ничего не сделать, только если ночами гонять под виртуалкой. Знаю некоторые организации, сотрудники которых не могут системы контроля версий внедрить — вот тут уже на начальство пенять нельзя, это в силах рядового разработчика поставить себе сервер.
Проблема в том, что инициатива всегда должна идти снизу, ответственность за проект, за сроки, всегда больше всего будет лежать на рядовом разработчике, но ни в коем случае не на начальнике. Тот, кто занимается организационными вопросами уже давно не технический специалист, инициатива от начальства крайне маловероятна. В большинстве случаев за проблемы в проекте начальнику скажут что-то устно, а работникам придется овертаймить, им откажут в повышении, не повысят зарплату из-за низкой эффективности и т.д. Потому нет вариантов — надо сидеть, и пробивать необходимые проекту решения снизу. Личным примером, а не насильно. Не теряешь вообще ничего на самом деле, если овертаймить приходится в любом случае — проще при этих овертаймах разобраться с причинами, их пофиксить. Если же овертаймов нет, то просто параллельно основной работе делать то, что никто больше сделать не может.
Здравствуйте, 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>Очень часто бывает что люди просто замечательные, а вот деньги никакие совсем
А как вы узнали про этих замечательных людей? Если не подошла зарплата, то знакомится с кем то кроме замечательного ХР — не нужно.
