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

V>Может проблема в том, что слишком много молодых и зеленых на конторе?
V>Может следовало бы костяк конторы из более опытных делать (со стажем
V>10-20 лет)?

Вы, видимо, и сами командой управлять сможете?

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

05.10.2012 18:23, IObserver пишет:

> Вы, видимо, и сами командой управлять сможете?
Управлял. Причем несколько раз на разных конторах. Но мне эта область
совсем неинтересна, посему отказываюсь категорически. Я больше делать
что-то люблю, чем на совещаниях пи... и в политику играть.

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

V>05.10.2012 17:29, UA пишет:

>> Поздравляю, вы сорвали презентацию демы которая являлась как условие для
>> получения контракта на 10 мегабаксов. Вы уволены!
V>)))))))). Давно так не ржал. Напугали ежа голой задницей.
V>Это манагер пусть развлекается дальше с "топами", я так так и скажу
V>вышестоящему начальству, что я его предупреждал, что ничего не выйдет,
V>он меня не послушал и не согласовал с заказчиком более адекватные сроки
V>или объем работы.

Но ведь конкурирующая фирма которая выиграла конкурс сделала это силами зеленого студента (он сделал это быстро и некачественно но этого было достаточно для презентации), как вы это им обьясните?

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

IO>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.
IO>Работали ли вы по такой схеме? Как вы ее оцените?

А потом этот разработчик как задумает небольшой рефакторинг на недельку, а потом как да выльется это в пару месяцев...
По такой схеме можно работать только если на результаты и сроки всем наплевать. Так можно, например, делать автоматизатор проверки соответствия кода внутренним стандартам кодирования компании или допиливать систему сборки или писать плагин для багтрекера, чтоб он лучше соответствовал принятому процессу, короче делать все что угодно кроме продукта.

IO>1. Есть список заданий по проекту.
хорошо

IO>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.
лучше определить Hero-line и Deadline
если успеет раньше Hero — поощрять
если не успевает за Deadline — должен объяснить почему

IO>3. Оплата разработчику стабильно в месяц, никак не коррелирует с количеством/сложностью выполненных заданий.
часто вынужденно так бывает, но не очень хорошо

IO>4. Каждый раз при "разборе полетов" негативные высказывания о состоянии дел, мол все получается медленно и дорого, нужно что-то менять.
лучше говорить конкретно почему всё плохо и кто козёл, причём лично ему
и плохо, если придираться из-за того, что всё плохо вцелом, к чему-то не имеющему отношения к настоящей причине промаха

IO>Работали ли вы по такой схеме? Как вы ее оцените?
да работал
для моего самоощущения даже лучше когда ставят рамки
иначе теряется ориентация — хорошо я работаю, плохо — иногда гнетёт, даже если мной на самом деле довольны

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

V>05.10.2012 13:18, Kernan пишет:

>> Например потому, что разработчик будет постоянно что-то улучшать или
>> попробует применить забубенную технологию в которой он 0.
V>Зачем? Не понимаю.

Resume-driven development. А как еще об украшении своего резюме заботиться, не "разводя" руководство на применение новых баззвордов?

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

IO>Как вам такая схема работы:

IO>1. Есть список заданий по проекту.
IO>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.

А если задачи связаны друг с другом ? Да и собственно, если делается продукт, то у него должен быть срок выхода. Хотя бы ориентировочный. Потом, помимо программистов есть тестеры, тех писатели (документация, help), локализаторы и т.п. Как всех синхронизировать, если каждый делает задачи сколько влезет ?

05.10.2012 18:46, UA пишет:

> Но ведь конкурирующая фирма которая выиграла конкурс сделала это силами
> зеленого студента (он сделал это быстро и некачественно но этого было
> достаточно для презентации), как вы это им обьясните?
Кому объяснять? Что? Что кто-то там что-то сделал (или не сделал), при
этом загорая на Канарах (силами зеленого студента).
Это их проблемы, я не мои. Тех кто "сделал".

06.10.2012 10:38, senglory пишет:

> Resume-driven development. А как еще об украшении своего резюме
> заботиться, не "разводя" руководство на применение новых баззвордов?\
Ужас какой. Обычно думаешь, что из резюме повыкидывать, а не каких новых
баззвордов добавить.

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

V>06.10.2012 10:38, senglory пишет:

>> Resume-driven development. А как еще об украшении своего резюме
>> заботиться, не "разводя" руководство на применение новых баззвордов?\
V>Ужас какой. Обычно думаешь, что из резюме повыкидывать, а не каких новых
V>баззвордов добавить.

Ну это для кого выкидывать, а для какой-то позиции наоборот, добавить. Просто есть смысл иметь длиннющее резюме, из к-рого методами фильрации и кромсания лепится что-то под позицию, на к-рое апплаишься с заточенным под них набором баззвордов. Чтобы хрюша читала и млела Вот для набивки исходного резюме как раз и имеет смысл навязывать баззворды в проекты.

IO>Как вам такая схема работы:

IO>1. Есть список заданий по проекту.
IO>2. Каждому разработчику выдается одно задание. Срок не оговаривается -- когда сделаешь, тогда и сделаешь.
IO>3. Оплата разработчику стабильно в месяц, никак не коррелирует с количеством/сложностью выполненных заданий.
IO>4. Каждый раз при "разборе полетов" негативные высказывания о состоянии дел, мол все получается медленно и дорого, нужно что-то менять.

Для чего такая схема в принципе пригодна — это для научно-исследовательской работы.
Когда нет готового решения, и надо чего-то новое придумать. Придумывание — это процесс случайный, и тут никаких сроков четко запланировать нельзя. Тогда можно сдеать так: назначить исполнителям фронт работ, пусть ковыряются. А когда придет время принимать какое-то конкретное решение — плясать от тех результатов, которые они успели на этот момент наковырять.