Цитата(AlexHuman @ 30.8.2010, 13:01  ) | | Из всего перечисленного понятно, что нужен ведущий разработчик |
Люблю наивных HR'ов. Давайте я расскажу с позиции специалиста. Вы нанимаете человека на довольно неплохую должность с солидной зарплатой. Вы должны понимать, что нормальный высокооплачиваемый специалист это не посудомойщик: он двести раз подумает, прежде чем менять работу, т.к. хороший послужной список очень важен.
Итак, что я не узнал из вашего описания вакансии:
1. Сфера деятельности компании (телеком, финансы, банковские системы, системы управления производством, бюджетные распилы и т.д.). Срок существования компании на рынке.
2. Численность сотрудников в компании. (<100, >100, >1000).
3. Численность сотрудников в подчинении! Вы, нанимая на должность ведущего разработчика, не удосужились уточнить, а сколько там других разработчиков.
4. Степень вовлечённости в менеджемент. Этот вопрос вытекает из предыдущего. Существуют разные концепции организации разработки ПО в соответствии с численностью сотрудников отдела. Если сотрудников не много, то можно обойтись одним человеком, который одновременно является менеджером проекта (следит за отчётностью, распределением работы и организовывает взаимодействие с другими отделами) и чистым ведущим разработчиком (комплексное проектирование системы, постановка задач для остальных разработчиков). В крупных отделах эти две роли разделяются.
5. Соответствие процедур разработки ПО отраслевым стандартам: ISO, DO-170b и т.д.
Чего вы от специалиста не потребовали:
1. Опыта руководства, ведения проекта.
2. Опыт проектирования архитектуры программных комплексов. В этот пунк входит море важных вещей (составление ТЗ, проектирование межкомпонентного взаимодействия, кластеризация и распараллеливание потоков данных и т.д.).
3. Опыт подгодтовки проекта и конечного кода к тестированию и/или верификации (тут уже много тех. деталей, как то: проектирование системы с учётом возможного unit тестирования, организация инструментирования кода, создание дополнительного ПО и интерфейсов для тестирования).
Всё вышеперечисленное это не столько технические детали, в которых вы ничего не понимаете, а организационно-правовые, которые вы, как HR должны знать досконально. Да и в технике хороший HR должен что-то понимать, хотябы на уровне основных определений. Прежде чем тупо перепечатать то что вам дали, вы должны были сотруднику разместившему заявку мозг взорвать по поводу деталей - это ваша работа. |
Можно сколько угодно долго обсуждать формулировки, но к сути это отношения не имеет.