Предлагаю собрать в данной теме разбросанные по всему форуму крупицы информации о том, какими знаниями необходимо обладать программисту, желающему устроиться на работу в должности стажера (самое начало карьеры) по направлению разработки корпоративного ПО на Java. Подчеркну: только корпоративного ПО, а не сайтов, инет-магазинов и пр.

Проанализировав несколько десятков подходящих объявлений о приеме на работу, я выделил примерный список того, что работодатели требуют в обязательном порядке:

• Java (как язык программирования)
• J2EE, а конкретнее:
  а) JDBC
  б) EJB
  в) Servlet
  г) JSP
• SQL
• составление документации

Достаточно ли этого? Может быть нужно что-то добавить\убавить? Понятно что у каждого работодателя свои требования, однако очень хотелось бы видеть некий усредненный список. Он очень поможет начинающим разработчикам тем, что они будут знать, что конкретно им нужно изучать для успешного приема на работу.

Особое внимание хочу обратить на то, что означенный список должен определять исключительно минимальный (базовый) уровень, необходимый для входа в мир корпоративного ПО. Конечно, Velocity, Spring Framework и прочие модные штучки это очень здорово, но сперва нужно заложить некоторое основание. Вот именно его и хотелось бы видеть в данной теме.

Заранее благодарю за участие!


Добавлено: по результатам обсуждения окончательный вариант списка выглядит примерно так:

- твердо знать:

• Java (как язык программирования)
• SQL
• javadoc
• CVS
• J2SE (основные средства стандартной библиотеки)
• ant
• JUnit
• servlets
• JSP

- иметь представление:

• MVC
• spring\strust framework
• hibernate
• JSF
• JMS // надо ли?
• EJB
• web-services
• дополнительные средства документации (TWiki, OpenOffice)

Это сообщение отредактировал(а) rsm - 5.7.2007, 09:49

SQL подразумевается.
Для минимального уровня знаний, имхо, наличие с списке сервлетов и JSP спорно. Скорее "очень желательно", чем "необходимо". Да и составление документации тут не к месту. Мой опыт показывает, что кодеры не умеют писать документацию, а те, кто умеет её писать, либо не умеют кодить, либо делают это плохо (исключения бывают, но это всего лишь редкие исключения из правила).

Логично, добавил.


А если разрабатываемое ПО имеет web-интерфейс? Что, кстати, совсем не редость (а скорее даже правило) для корпоративок.


Кто ж тогда ее пишет? 

Это как? Львиная доля корпоративного ПО имеет веб интерфейс. Даже сам написал:



а с сайтами возиться не хочешь.   

Впрочем, позволю себе высказать свое IMHO:
Лучше выбрать одно J2EE направление и быть гуру в нем, а не рассеиваться по всему сразу. Например View Tier (HTML, AJAX, Servlet, JSP, JSF, Java Script ...) или Business Tier (Spring, EJB, Web Services, Quartz ...) или Data Tier (SQL, XML, Hibernate, Java Persistence, XQuery, Lucene...)  Это я говорю по тому, что J2EE невероятна большая и динамично развивающаяся технология. Знания устаревают на днях. То что было современно 3 года назад сейчас уже никому нужно. Только если в команду поддержки ПО не попадешь. Выучить все очень непросто, а эксперты везде нужны... Хотя, конечно же, как минимум, ознакомленным нужно быть со всем...

Добавлено через 52 секунды

Technical Writer

ну и какую же выбрать?


кодеры пишут тест-кейсы , так что 

всё таки надо

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


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

Это уже скатывается к дискуссии, что есть "сайт", а что - "вэб-интерфейс". Имхо, многие корпоративные проекты имеют не только вэб-интерфейс, но и полнофункциональную структуру сайта.


Смотря, чего хочет работодатель. Если он хочет мальчика на побегушках, который будет латать дыры в проекте - нужен человек, который сносно разбирается во всём. Если он желает создавать современные продукты с высоким качеством - придётся искать специалистов.


Хм... три человека - это много? А ведь разделение будет уже достаточным, чтобы они успешно выполняли проекты. Конечно, если это будут специалисты, а не новички.

Какая больше нравится, ту и выбирай.   


Лично для меня, web интерфейс и сайт это одно и тоже. Поскольку работать с ним приходится через Web-браузер. Технология все равно сводятся к отправке HTML разметки браузеру клиента. Или клиент это не браузер, а GUI программа?


Не думаю что всегда. Все от организации труда в конторе зависит. Бывают большие конторы и большие проекты, а бывают не очень. Бывают команды где 15 студентов и пару матерых спецов, а бывают где штук 7 спецов и все. Просто последние везде нужны. Это факт. 
Впрочем я конечно же не утверждаю, что нужно обязательно учить что-то одно... можно все и сразу. Это как ты сам хочешь: в ширь или в глубь копать.

P.S:
Вот я в своем первом посте написал 16 различных технологий (причем далеко еще не все). Даже если уделять каждой на серьезное изучение по 1 месяцу то уйдет примерно полтора года (хотя тут от человека сильно зависит). За полтора года, выйдут новые версии библиотек и где поменяют (добавят фитч) процентов на 20, или придут более "модные" технологии. А если чем то постоянно не пользоваться то это забывается, значит все нужно заново повторять. Мне вообще парой кажется, что людей разрабатывающих новые технологии гораздо больше чем их использующих  Вывод могу сделать такой: Хочешь трудится в j2ee сфере готовься к постоянному самообразованию. 

Добавлю свои 5 копеек. 

Во-первых, я бы разделил технологии (стандарты) и их реализации. Например, сервлеты и JSP - это технологии, а Tomcat, Jetty, Resin - это реализации. Предполагается, что веб-приложение, написанное с помощью JSP и сервлетов будет работать с любой реализацией. Если рассматривать Tomcat и Jetty, то я почти уверен, что так и будет, если же тоже самое приложение попытаться запустить на IBM Websphere, я бы поостерегся говорить так однозначно. Мораль - любая реализация обладает своими особенностями, которые в общем-то нужно знать, но приходит это с опытом. И в первую очередь нужно знать технологии.  

Во-вторых, рассмотрим те же JSP и сервлеты. Это те технологии, которые точно нужно знать если ты собираешься разрабатывать веб-приложения. Но! Их точно нужно знать если ты в ближайшем будущем собираешься участвовать в разработке коммерческих проектов. Есть множество людей, убежденных, что Velocity - гораздо лучшая альтернатива JSP (я в их числе), тем не менее в работе приходится использовать JSP и ни что иное. По той простой причине, что это стандарт де-факто и пиарится Sun, хотя может быть и использование Velocity было бы гораздо более эффективным. Поэтому для участия в коммерческих проектах (если конечно, не ты сам организатор проекта и не определяешь чем пользоваться), нужно знать стандартные вещи - JSP, сервлеты, JMS, веб-сервисы и т.п.

В третьих, специализация на каком-то одном tier может быть и верна, но на самом раннем этапе карьеры программиста. Велика вероятность того, что при переходе на новый проект ты скажешь, что хочешь заниматься data tier, а менеджер проекта тебе ответит: "Да у меня таких уже 5 человек, а займись-ка ты, дружок, веб-вервисами". Думаю, иметь представление нужно обо всем. И готовиться постоянно изучать что-то новое. Честно скажу, заниматься этим приходится ежедневно. Долго продержаться с каким-то ограниченным запасом знаний вряд ли представляется возможным. Мой небольшой опыт программирования на Delphi когда-то убедил меня в том, что можно наизусть знать все API и писать не заглядывая в документацию. Так вот, с J2EE так не пройдет, здесь помнить все - не в человеческих силах, всего очень много, при этом это самое "все" постоянно меняется.

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

Ну и последнее. Все-таки, самый быстрый путь изучения - это туториал от Sun. Единственное "но" - тот сервер приложений, который у них используется в примерах (Sun application server) на практике встречается очень редко, скорее всего придется переходить на что-то другое.

Нет, они существуют, но "сырьё" для них всё равно должен предоставлять разработчик.


Неужели отличия достаточно значительны?

Нет конечно, технологии везде одни и те же. Но иногда там описываются вещи, которые генерируются или создаются инструментами SAP. Средства других серверов приложений могут сильно отличаются.

Как я понимаю, дело обстоит обратным образом: то, что запускается на Tomcat, должно запускаться везде, потому что Tomcat это reference implementation - эталон - для спецификаций servlets&JSP. Если кто-то говорит, что он эти спецификации реализует, то все, что запускается на Tomcat, должно запускаться и у него. 

С другой стороны, то, что разработано под некоторым application server (WebSphere, WebLogic, JBoss, SAP) - может быть (скорее даже - "чаще всего") непереносимо (по меньшей мере, без дополнительных трудностей).

Добавлено @ 14:02

+1


Это сообщение отредактировал(а) Ulysses4j - 26.6.2007, 14:34

Согласен, в Tomcat об этом говорят. Скорее всего, потому что Tomcat разрабатывают сотрудники Sun.


Где такое написано? Серверы приложений J2EE проходят соответствующую сертификацию у Sun. В процессе сертификации, насколько я знаю, не сказано, что веб-контейнер должен работать идентитично Tomcat.


Как я понимаю, если сервер приложений прошел сертификацию у Sun, то приложения должны быть переносимы, за исключением деталей, которые зависимы от разработчика (они явно указаны в спецификации). Тогда мне совершенно не понятно почему в Websphere 6.1 ранних версий жизненный цикл обработки запроса не соответствует спецификации, хотя Websphere сертификацию прошел.

В смысле, это те сотрудники, которые по совместительству состоят в ASF? ;)


Каюсь, ссылку привести не могу.


Этого не сказал и я: я не говорил, что работать должны идентично, я сказал, что то, что запускатся на Tomcat, должно запускать в других местах, потому что Tomcat  предоставляет минимальную функциональность сервлет-контейнера, а app-серверы - надмножество этой функциональности:

Все, что я сказал выше, в основном вытекает из этого представления о надмножестве. 

Про ситуацию с WebSphere ничего сказать не могу.

ЗЫ Это все, наверное, жуткий оффтоп пошел. Прошу прощения. Надеюсь, мы как-то остановимся.

Это сообщение отредактировал(а) Ulysses4j - 26.6.2007, 19:04

Главное, чтобы интересно было. И это правило соблюдено 

Примем условно для ясности, что в данной конкретной теме под сайтом понимается программа с web-интерфейсом, которая работает в Инете. А под корпоративной программой с web-интерфейсом понимается программа, которая работает только в интранете.


По сути возражений нет, тонко разделить обязанности - это правильно. Однако в реальности почему-то обычно все совсем не так как хотелось бы 

2 tux: хороший пост, спасибо! Если можно, то хотелось бы чуть побольше конкретики относительно перечня технологий, которые следует знать стажеру Java. Кое-что уже названо (JSP, сервлеты, JMS, веб-сервисы), но может есть еще что-то?

2 ALL: с учетом поста tux список знаний будет выглядеть так:

• Java (как язык программирования)
• J2EE, а конкретнее:
    а) JDBC
    б) EJB
    в) servlets
    г) JSP
    д) JMS
    е) web-services
• SQL
• составление документации

Если все согласятся, поправлю его в шапке.


Кстати о документации: может кто-нибудь добавит пару наиболее популярных средств для документирования? Их тоже не мешало бы включить в список, т.к. документирование можно понимать по-разному - как применение специализированных средств, так и ведение заметок "на полях" в простейшем текстовом редакторе.

Word, куда же без него. Местами - картинки (Visio). Ну и javadoc, естественно, никто не отменял.

А более переносимое? Ведь Java в отличие от NET существует не только для платформы Wintel.

Ну, OpenOffice. Суть не меняется.

TWiki

Понятно. Не понятно только что имел ввиду товарищ Chopra. Есть спецификация J2EE, сервлеты и JSP - это ее часть. Tomcat реализует только сервлеты и JSP, а, например, JBoss - спецификацию целиком. Он не считает Tomcat сервером приложений и разница между J2EE и servlets и есть тот superset? Или что серверы приложений к servlet api добавляют что-то свое и это искомый superset? Так и в Tomcat тоже самое - это superset над servlets api. В общем, не поймешь этих индусов.


Да я бы понаписал много чего, проблема в том, что все зависит от конкретного проекта, на который попадешь. Главное знать базовые вещи, а изучать все равно что-то придется, здесь сложно угадать. На изучение время как правило дают, тем более стажеру. Библиотек разных великое множество, используется обычно то, что архитектору в голову придет или то, что заказчик диктует. В общем, точный список привести вряд ли кто-то сможет.

Так ведь именно про них я и спрашиваю, только ради них и создавал эту тему! 
Что это за базовые вещи, можно их перечислить? 

Дак об этом уже все сказали. Базовые библиотеки J2SE, сервлеты, JSP. С остальным вряд ли угадаешь.

Можно отсюда поподробнее? Библиотек в J2SE - тьма. Какие изучать-то?

Дык все и изучать. Как я уже говорил, помнить все невозможно, но знать какие есть классы и что можно сделать средствами стандартной библиотеки нужно. Вообще советовал бы вот этот двухтомник как источник базового знания - http://www.books.ru/shop/books/393818.

Добавил бы

ANT или Maven
JUnit

Так же желательно иметь представление о:
Struts или Spring MVC
Hibernate

- твердо знать:
• Java (как язык программирования)
• J2SE (основные средства стандартной библиотеки)
• J2EE, а конкретнее:
      а) EJB
      б) servlets
      в) JSP
      г) JMS
      д) web-services
• SQL
• составление документации (TWiki, javadoc, OpenOffice)
• ant
• JUnit
  
  - иметь представление:
• MVC
• spring\strust framework
• hibernate

Так лучше?

Лучше, но чтобы это все "твердо знать"... Я два года плотно со всем этим работаю, и не скажу, что знаю твердо.

Еще неплохо бы знать какие нибудь системы контроля версий. (SVN, CVS, ClearCase...)

Ребята, а по чему нет jsf?
ведь это тоже стандарт, пришедший на смену jsp.

Лидер, на мой взгляд, svn.

jsf eto vsego frejmwork. Katorij prodvigaet SUN i on vhodit j2ee sdk. A jsp eto servernie stranci ih ne kto ne otmenjal.
Ja bi sostavil spisok takoj:
 - java se
 - jsp (jstl,custom tags)
 - servlets
 - jakarta commons (file upload, bean-utils....)
 - horosho znat' Tomcat
 - loggirovanie
 - xml/xsd/xslt
 - kakojnibut'  framework struts/jsf
 - uml
 - junit
 - ant
 - sql + plsql + jdbc
 - velocity
 - JS
 - XHTML
 dlja verhovnih ka4ej:
 - ejb
 - hibernate
 - axis 

Vot takie pirogi. 
P.S.  Nas4jot togo 4to nado znat' vsjo. Vsjo ne polu4itsja (vprincipi realno). Tozhe ho4etsja imet' li4nuju zhizn' i pro4ee. Tipa: zaroshij ne britij, zhena brosila, deti ignorirujut, no zato znaju JSR XXX.  . Na moj vzgljad nado hoorosho zant' osnovi, ili smezhnie tehnologii. Naprimer znaesh struts bistro razberjoshsja s jsf i td.... Ponimaesh custom tagi, predstavjaesh kak rabotajut napriemer struts. Sootvetstvenno men'she tratish vremeni na izu4enie.    

Это сообщение отредактировал(а) Tony - 28.6.2007, 21:21

на мой взгляд разговор ни о чем.
каждому работодателю нужно что то свое. смотри на hh.ru
Времени изучить при полной занятости нет ине будет. Единственный шанс это много проектов под разные технологии, но заказчики люди разные, одни хотят передовые технологии, другие поддерживают старые и проверенные.
насчет юазовых знаний =) блок схему рисовать умеешь? да? берем! =))))

PS удивительно что никто еще не вспомнил про паттерны, так же без знаний SE в EE делать нечего.
мерятся можно много, толку от этого не будет никакого. Если человек соображающий работодатель сам научит или даст время на изучение тенологий.
Я знаю пример когда люди написали свой фреймворк и успешно им торгуют и без всяких "крутых" технологий.

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

2Tony: список хорош, слов нет. Но все ли из перечисленного надо знать СТАЖЕРУ Java, который только вчера закрыл последнюю страницу учебника, а сегодня пришел устраиваться на работу? Я в этой теме пытаюсь собрать базу знаний для стажеров и только стажеров, а не senior developer'ов c пятилетним стажем.


Уже смотрел. Именно потому и создал тему, чтобы попытаться хоть как-то устаканить требования к стажерам Java.

Da. Mne samomu skoro nado budet prohodit' praktiku po specialnosti   . No ja sebja gotovil neskolko let (znal 4ego ho4u). Ja i mel opit prohozhdenija praktiki v kompashe, poetomu znaju 4to nado. Kone4no esli na4at' koderom so znanijami sevlets/jsp , java API, to budet diko tjazhelo. Eto kak verjovaka. Djorgnul a tam... i td.  . Poetomu esli est' eshjo vremja do stazheroki begom 4itat' knigi, pisat' kod i nabivat' ruku.

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

2 ALL: пользуясь затишьем в теме подведу итоги:

- твердо знать:

• Java (как язык программирования)
• J2SE (основные средства стандартной библиотеки)
• J2EE, а конкретнее:
    а) EJB
    б) servlets
    в) JSP
    г) JMS
    д) web-services
• SQL
• составление документации (TWiki, javadoc, OpenOffice)
• ant
• JUnit
• CVS

- иметь представление:

• MVC
• spring\strust framework
• hibernate
• JSF

я бы сделал немного другие выводы.
Помоему ты описал слишком уж жёсткие требования для "java - стажёра"(junior java developer).
ИМХО, Вместо "твёрдо знать" надо поставить "иметь представление", а вместо "иметь представление" - "знать определение".
А главное требование - это наличие головы и в ней наличие мозгов, что позволяет самообучаться. Да, конечно, надо ориентироватся во всей предметной области, что-бы не попасть в просак. Так что "HelloWorld" по последним 4м пунктам и по 5 "лабораторных работ" на каждый из первых пунктов и я думаю можно смело отправлять резюме  на вакансию junior java developer. 
На первой странице правильно написали, на каждую из перечисленных технологий надо потратить хотя-бы месяц, по твоему списку обучение займёт полтора года. 

Перечень технологий J2EE я брал из реальных объявлений приема на работу. Поэтому сокращать или переносить их в список "иметь представление" ИМХО будет неправильно.


Очень быстро ничего и не бывает. Другое дело что за это время приоритет используемых технологий может поменяться и тогда твои знания станут бесполезны. Единственный, на мой взгляд, выход из этого положения - это придерживаться курса "Солнечного Брата". Если Sun делает упор на JSP и JSF, то изучать следует в первую и главную очередь именно их, а не Struts, Spring и прочие Castor'ки. Потому что свободные сторонние разработки это конечно очень здорово, но именно технологии Sun составляют мэйнстрим. Хотя может быть я категорически не прав и участники темы предложат иное мнение?

Эти объявления всегда завышены. Как правило, если в списке в числе прочего указано "Hibernate", то диалог развивается так: "C Hibernate работали?" - "Нет" - "А что это такое и зачем нужно, знаете?" - "Да" - "Ну тогда быстро научитесь".


Не сказал бы. Примеров использования Struts я знаю больше, чем примеров использования JSF. Правда, последние и появились позже.

Помоему мы начинаем повторятся.
Итак. С технологиями, имхо, ты определился верно именно они являются самыми востребованными, на данный момент.
Осталось определится для себя в какой мере их надо изучать. Опять таки, имхо, следует только освоить только некие основы каждой из перечисленных технологий и стараться уже искать место в комерческих проектах для получения практического опыта.
На сколько знаю, никто не возьмёт в контору программиста с улици на ведущую должность (хоть какие бы у него знания не были),  если у него нету практического опыта работы. (Ты перечислил нужные технологии из java-вакансий, но в каждой вакансии есть ещё пункт опыт работы или "участие в реальных проектах" ).
не так ли?

У меня из последнего списка вызывает сомнение JMS. 

web-services я бы перенес в "иметь представление".

И зачем там OpenOffice - ума не приложу.

Это сообщение отредактировал(а) Ulysses4j - 1.7.2007, 12:20

Ja tozhe ne dogonaju   . Pri4jom tut OpenOffice ?

Надо было прочитать обсуждение.
Это типо кроссплатформенный редактор тестов(документации).

Типа кроссплатформенных редакторов текстов до отвала, и OpenOffice не может претендовать на роль стандарта в этом деле - ни де-факто, ни, естественно, де-юре.

  
такого же функционального уровня.

Это ирония? *сорри, просто плохо с ЧЮ* Такая функциональность часто становится обузой, а не подспорьем. Не представляю себе документации, для составления которой потребовалась значительная часть функционала ОО. Впрочем, я не настаиваю: хотите - изучайте. Просто ставить в обязательные требования этот продукт мне кажется неверным.

Ну почему же. Вопрос на самом деле актуальный. Вот например у нас в проекте активно используют MS Office и TWiki. Все документы которые относятся к процессу (FS, HLD, ...) пишут в MS Word. Различные Meeting Minutes, Issues и некоторые другие документы - TWiki. Наиболее приближенный к MS Office продукт это OpenOffice. Вот мне и хотелось оценить возможные альтернативы как MS Office, так и OpenOffice. 


Да те же таблицы и вставка картинок в документ - банально, да не всякий продукт может. Редактор электронных таблиц (MS Excel. OO Calc) тоже бывает к месту.


совершенно согласен.

Не так. Я специально подбирал объявления без требований опыта работы.


Принято.

- твердо знать:

• Java (как язык программирования)
• SQL
• javadoc
• CVS
• J2SE (основные средства стандартной библиотеки)
• ant
• JUnit
• servlets
• JSP

- иметь представление:

• MVC
• spring\strust framework
• hibernate
• JSF
• JMS // надо ли?
• EJB
• web-services
• дополнительные средства документации (TWiki, OpenOffice)

Перенес EJB в раздел "иметь представление" т.к. судя по отзывам в других темах его не очень-то почитают как программеры, так и управленцы.

Я бы перенес в "иметь представление" также ant, javadoc, JUnit.

Потому как научиться пользоваться этими тулзами можно за два-три часа в достаточной мере, а на тех же собеседованиях про них спрашивают крайне редко.

Это сообщение отредактировал(а) ecologist - 3.7.2007, 09:32

ИМХО перенести стоит только ant. Потому что javadoc и JUnit в идеале должны быть "продолжением руки", обязательным неотъемлемым атрибутом любой программы, даже "Hello, World!".

rsm, у нас, так все наоборот - javadoc и JUnit не нужно, а вот с Ant'ом мы ковыряемся очень плотно.

Обновил список в шапке.

И где логика? Если ими можно научиться пользоваться всего за два-три часа, то, я думаю, это нужно сделать.... чтобы не просто иметь представление.

Логика в том, что чем больше ты изучаешь за ограниченное время, тем меньше усваиваешь и понимаешь. В голове будет каша. Будешь чувствовать себя неуверенно. Следовательно, если есть возможность уменьшить объём, стоит ею воспользоваться. Как только первичные знания усвоены - можно и дополнительные усвоить, благо часть из них много времени не отнимает.  

И ничто не написано про xml?

всё включено.

checkstyle в обязательном порядке     // чистота превыше всего   

Это сообщение отредактировал(а) polosatij - 13.9.2008, 16:56

[QUOTE=rsm,2.7.2007,  07:35]
перенесите обратно. EJB3 / JPA почитаются и нашими программерами и нашими управленцами

Я сейчас работаю в проекте где также используют EJB и JPA. Почитание среди программистов и управленцев тоже нормальное. 

Присоединяюсь.