Сообщений в теме: 44

[Case]

У меня в команде таких тракторов два (все облизнулись) и еще один танк (захлеб слюнями) и один кандидат на броненосца

Guriy, не травите душу? :) Я сейчас как раз в процессе поиска человека, а вы тут раны бередите.

[Volant]

У меня в команде таких тракторов два (все облизнулись) и еще один танк (захлеб слюнями) и один кандидат на броненосца

Guriy, не травите душу? :) Я сейчас как раз в процессе поиска человека, а вы тут раны бередите.

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

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

С уважением,
Николай

[aleksey_kh]

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

Согласен.

Это перестало быть конструктивным обсуждением... я пытался сказать, что, как я понимаю (и немного вижу ;), менеджер должен построить различные модели своего коллектива (состав по опыту, времена вероятного ухода работников, набор компенсаций, организация процесса разработки, риски)...
Сравнив несколько вариантов выбрать и преступить к реализации наиболее оптимального...

Я и спросил совета у кого был опыт и т.д. а тут начали флудить и высказывать свое мнение не имея опыта(всем конечно спасибо, но просьба о совете включала слово опыт).

... один супер дядя автор поста, рассказы про текучесть студентов и выпускников на более большие зарплаты...

То что я "супер дядя" я не говрил, а нооборот сказал что за своими "соплями" смотреть некогда...


Если больше никто опытом поделится не может , то предлагаю закрыть тему .....



Всем спасибо за "experience",
Особая благодарность любителям давать советы. ;)

[PeterL]

Гляжу, тёмная сторона, набирает силу в этом топике... :D

И, дабы вернутся к светлой стороне и расставить точки над i, хочу ещё раз изложить свою точку зрения от и до, чтобы избежать непонимания. Эта точка зрение не претендует на единственность и правильность.

Начнём с начала, автору топика было предложено:

Взять хороших программистов (или хороших программисток, если кто-то усмотрел дискриминацию). И держать, чтобы не ушли, пока не разработают хороший регрессионный комплект тестов. Потом оставить четверть из них на поддержку, а остальных отпустить. А оставшимся ещё приподнять зарплату, чтобы не разбегались.

Мне кажется что:

а) Хорошие (неплохие) программисты не пойдут на такую работу, если им не будет предлагаться достаточно большая зарплата, а я думаю не секрет что в среднем скриптописатель из отдела автоматизированного тестирования получают меньше чем девелоперы.
Приведу пример: что для хорошего программиста з\п в 1500$ чуть выше среднего (со слов моего друга, который недавно устроился), а для тестера\скриптописателя (не QA менеджера) это очень и очень хорошо.

б). Предложение нанять вместо 4ых студентов\выпусников хороших программистов - а смысл(?), если и студенты\выпусники могут писать скрипты, может не так быстро и хорошо как программисты, но могут и пишут, становяться в итоге хорошими программистами и сваливают на более высокую з\п, разнообразно-интересную работу или просто сваливают потому что надоедает.

с). Не знаю как везде, а у нас приёмом кадров и з\п занимается не Тим Лид а менеджмент компании, а Тим Лид даёт ему (менеджменту) рекомендации\комментарии по сотруднику. Так что не Тим Лид решает кого нанимать: "матёрых" девелоперов или студентов, а его задача чтобы весь этот набранный тим нормально функционировал, т.е. создание условий работы для того чтобы люди не сваливали:

1). Добиваться чтоб хорошим работникам достойно поднимали з\п.
2). Поддерживать хорошую атмосферу в коллективе.
3). Стараться добавить интереса и разнообразия к работе (по возможности).

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

2 barancev
Алексей, ну с супердевелоперами я, конечно погорячился, прошу прощения. :)

[barancev]

А ведь в самом деле, автор просил не советы давать, а просто опытом поделиться. Конечно, давание советов это одна из форм передачи опыта. Возможны другие. Давайте просто расскажу, как у нас организовано.

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

Вот так мы работаем. И поэтому у нес нет проблемы с тем, что хороший программист не хочет идти в тестировщики. Почему нет, если зарплата та же, а челлендж в тестировании часто покруче, чем в разработке?