Aprior IT
Опубликовано 07.05.2006 в ИТ, Днепропетровск(данные предоставлены сотрудником компании)
Компания существует больше 4 лет и работает на рынках Северной Америки, Австралии, развитых стран Европы и Азии.
Предпочтение отдается тем задачам в области системного и продвинутого программирования, решение которых позволяет использовать современные технологии и/или требует изучения недокументированных возможностей протоколов, компиляторов, ОС и т.п.
В качестве языков разработки, в основном, используются С, С++ и C#; приоритетные платформы – Win32 и Linux.
По волшебному тесту Джоэля на данный момент 10 баллов.
Особенности компании:
- Ориентация на развитие как сотрудников, так и компании в целом. С учетом этого принципа отбираются проекты, назначаются задачи, формируются команды. Разработчики также имеют возможность выбирать направление специализации и менять его через определенный срок, чтобы расширить знания/навыки/опыт.
- Демократичность и открытость рабочих отношений, здоровая внутренняя атмосфера.
- Возможность подобрать удобный для себя график работы (в случае разработчиков, согласовывается с менеджером).
- Бытовой комфорт.
- Оплачиваемый компанией отдых (театр, море, внутренние праздники) + стандартный отпуск.
Студентов на данный момент (принимаются только старшекурсники)- 6%.
Зарплаты пересматриваются регулярно, индивидуально и напрямую зависят от качества и эффективности работы, знаний и опыта. Практикуются ежемесячные надбавки-бонусы по результатам работы.
Испытательный срок длится до 2 месяцев.
Цепочка карьерного роста для сотрудников-разработчиков:
Младший разработчик -> разработчик -> старший разработчик -> тим лидер -> проектный менеджер. Количество позиций на первых трех уровнях не ограничено. Срок пребывания на каждом из них зависит от тех же факторов, что и зарплата.
Дополнительную информацию можно получить на корпоративном сайте и, если Вам интересна работа в компании, по адресу сv@корпоративный_домен.
)
@artyom.bondartsov
Хочтелось бы объяснить, что своим постом я не ставил себе целью засрать АприорИТ. Тем более создать рекламу. Я просто поделился информацией о достоинствах и недостатках. Но излишний ПиАр с вашей, Артемий, стороны немного подозрителен. Тем более что спецификация всех Айти компаний Украины, да и везде пожалуй - ЗАРАБОТАТЬ БАБЛО, МНОГО БАБЛА! А какие ХэПэ, У-Пэ и прочие красивые вещи применяете - это, батенька, директора не интересует. Реальнее давайте относится к вещам, не надо этого фанатизма!
И внимание вопрос: сколько процентов ньюдевелопмента у вас от всей кучи проэктов?
Что же, если процесс появился — можно только порадоваться. Без шуток. Я бы посоветовал еще иметь такую практику как ревью кода. Я бы ограничился даже не peer review, а senior review для junior developers. Если, конечно, эту практику еще не внедрили.
Артем, что до критериев оценки эффективности, то они не всегда волнуют работника больше всего, как мне кажется. Т.е. не всегда самая эффективная компания — наиболее привлекательное место. Думаю, что критериев привлекательности для сотрудников, я согласен с ExWorker: количество пришедших это не критерий. Я бы считал по количеству ушедших.
Артем, простите, я немного вас поправлю;)
Немного некорректно звучат фразы насчет:
присутствует RUP - RUP это разновидность UP, откорректированая компанией Rational, для ее использования, они предлагают ряд шаблонов документаций, и ее описание, у вас они есть? вы покупали их? или же вы все таки UP используете?
кто-то использует элементы MSF - например написание кода - часть любого процесса разработки, поэтому “использует элелементы процесса разработки” можно сказать, просто если человек пишет код, а в некоторых методологиях вообще заявляется, что они работают только когда все шаги выполнены, поэтому уточняйте пожалуйста, что именно вы используете из MSF.
кто-то заглядывается на Agile - тут я вас поправлю, Agile - целый класс методологий, XP и RUP - Agile методологии (скорее всего и MSF).
Если это не коммерческая тайна, и мы уже затронули эту тему, расскажите пожалуйста подробнее про процессы разработки? И какие типы проектов у вас бывают, какие навыки умения треубются от разработчиков? Что входит в обязанности синьйоров и тим лидов и проджек менеджеров?
интересующийся, Вы уверены, что RUP это Agile методология??
Немного переврал, хотел сказать UP - Agile, RUP это его разновидность, но чем именно он от UP отличается сказать немогу, поэтому за него лучше промолчу.
Крег Ларман называет его Agile и Фаулер помоему, если будет очень интересно, могу цитаты и ссылки дать:)
По Крегу Ларману - Agile методологии - те которые позволяют вносить изменения в требования после начала разработки, благодаря итеративной разработке в UP это достигается. Есть и еще у него критерии, им тоже UP удовлетворяет.
Возможно информация, которую сейчас изложу немного устарела, но я думаю что все-таки в целом мало что поменялось.
Нормального стандартизированного процесса в Априорите нет и не надо выдавать желаемое за действительное. Пользуются элементами разных подходов, т.к. книжки читают). Например, при мне вводился ХП.
На самом деле особенность априорита в том, что в нем нет четкой иерархии девелоперов (хотя тим-лидеры как-бы есть). Т.е. тебе не говорят, что делать, ты сам решаешь как делать задачу.
С одной стороны это плохо, т.к. каждый колбасит что-то свое и заставить заработать эту кучу разнородного кода очень сложно. С другой, работать без указки гораздо приятнее ). Хотя тогда ответственность за провал и срыв сроков большей частью сваливается на девелопера. Передача опыта от старших младшим не наблюдается.
Потом что касается проектов, то существуют долгие проекты с суппоротом, бывают и новые. Смотря куда попадешь. Надо сказать, что процент новых проектов достаточно большой. Конечно приятнее писать все с нуля, чем заниматься пожизненным суппортом какого-нибудь монстра. Мне например, за все время работы в Априорите суппортить не пришлось. Но это не значит что суппорта нет совсем).
Насчет зарплат, то они средние, имеют свойство повышаться в отличие от других контор. Зарплату не задерживают.
Подитожу: в априорите процесс разработки сильно хаотичен, но значительно свободнее чем других конторах. Суппорта меньше, но есть.
@Plohish brother
Не стоит сомневаться в Артеме, он редкий идеалист (всегда им был) и говорит от души. А вот остальные люди в Априорите гораздо приземленнее. ))
В целом я почти со всем сказанным Вами согласен. Единственное что размер зарплаты определяет не все при выборе работы. Хочется иметь хорошую работу при хорошей зарплате, а не только хорошую зарплату. ))
@alexdolgin,
).
спасибо за совет. у нас 90% кода проходит review, и причем ревьювится код не только джуниоров, а и сеньоров (конечно, не джуниорами
а так интересно почитать. Тёмик жжот. Официально заявляю что это его личная позиция, но я конечно рад что у него (и отнюдь не только у него) она такая.
насчет эффективности советую посмотреть сюда
http://positivesharing.com/2007/03/top-10-reasons-why-happiness-at-work-is-the-ultimate-productivity-booster/
просто быть счастливым на работе повышает эффективность работы в разы больше остальных методов. У нас в компании мы предпочитаем действовать (или по крайней мере стараться действовать) именно таким образом для повышения эффективности.
@others
привет бывшим сотрудникам Априорита. хорошо, что вас так много. может быть, именно таким образом остальные компании города будут иметь возможность работать с людьми, у которых вполне резонно завышены требования к работе - как к наполнению, так и ко всему остальному. и, глядишь, мы быстрее станем культурным городом (или хотя бы сообществом).
Unknown, спасибо за столь лестный отзыв обо мне! Такого пиара моего офиц. имени даже на сайте АприорИТа не было
И если мы теперь будем говорить обо мне, то должен предупредить сразу - я не одет, не причесан и не накрашен 
В остальном же, Unknown, вот какие есть мысли. Обычно так случается, что порой оглядываясь назад, кто то из нас может заметить, что определенная часть жизни в воспоминаниях отсутствует. Таким образом, как мы, например, можем не помнить части своего детства. Как, впервые больно ударились или кто и что нас окружал, когда впервые ругнулись взрослым матом или подрались.
И это нормально, обычная функция памяти. Бывает, что просто нечего вспомнить, ну … просто потому что нечего, а бывает, что и вспоминать вовсе не хочется. Ты когда то ушел с АприорИТа по каким то своим соображениям, безусловно актуальным для тебя. Очевидно, что ты нашел для себя это актуальное сейчас. И вот сейчас, в своем нынешнем состоянии можешь ли ты самому себе признаться, отразится ли этот изрядный кусок твоей жизни, связанный с нынешним местом работы приятными и теплыми воспоминаниями в твоей памяти? Будет ли что вспомнить после, по прошествии многих лет о большей части твоей сознательной жизни? Что это будет, просто работа, просто деньги или будет также что то приятное? Ты можешь не отвечать мне, а вот с собой будь честным до конца, потому что мы когда то с тобой работали вместе и я буду только рад, если твой ответ тебя полностью удовлетворит 
Что же до остального, я об этом как раз и говорю. Твой пост лишний раз подтверждает правдивость моих слов о независимых командах.
Кстати, о какой стандартизации речь? Как это происходит, на гос уровне выдается бумажка с печатями авторитетов или как то иначе? Я на самом деле не знаю, поясни мысль. Потому что ты опять нас вернул к тому, с чего мы начали.
Есть также то, про что ты умалчиваешь. Ты верно сказал, ответственность за провал, но не вина за провал. И вот теперь припомни, сколько их было? Правильно ли я понял, что тебе что то не нравилось в твоей команде? Ты пробовал что то предпринять по этому поводу? Ведь полномочия командам даются со всеми вытекающими последствиями - ответственность за провал, но также и ответственность за собственный проф. рост и качественные изменения в команде. Ведь это не выборочно-удобное для нас понимание ответственности, почему ты говоришь о первом не упоминая последнее, что конкретно тебе запрещалось делать?
По проектам ты лишь забыл упомянуть, что сотрудник волен переходить на любые интересующие его проекты, в любые команды по собственному желанию. Это считается нормальным и для этого всего лишь достаточно уведомить руководство.
Также как забыл упомянуть, что производить рефакторинг на суппорте тоже бывает приятно. Особенно если не рефакторить с нуля, а хотя бы воспользоваться рекомендациями упомянутого выше Фаулера.
Блин, я не могу это читать )))))
Темик, ты зашел в чересчур большие дебри.
Что касается того нравилось ли мне работать в Априорите, скажу что поначалу очень сильно нравилось. Потом захотелось больше денег. И стало меньше нравится ))). В общем стандартная ситуация.
Что касается процесса, то там где я работаю сейчас, любое, подчеркиваю, любое решение аппрувится тим лидером, потом архитектором. Причем и тот и другой его реально смотрит и вполне может прислать на переработку. И вообще процесс описан в документации.
Да и еще специально для тебя, Темик, скажу, что интересную работу можно найти не только в Априорите.
@artyom.bondartsov
“что сотрудник волен переходить на любые интересующие его проекты, в любые команды по собственному желанию”.
Очень интересно получаеться. Фирма “Априорит” находит заказчика и проект, на который нужно 3 c++ девелопера. “Априорит” устраивает собеседование, и приглашает на работу 3 специалистов.
Отработав 2 месяца и пройдя испытательный срок, новые сотрудники решают, что им этот проект не интересен.
И “Априорит” с улыбкой на лице предлагает им перейти на проект, в котором недостатка в програмистах нет.
Я правильно описал возможный сценарий?
интересующийся, да, я не стану настаивать на исключительной корректности. Ибо по моему убеждению, общий знаменатель под различными трактованиями этих методов как раз и заставляет их работать. Неукоснительное соблюдение … у меня нет оснований не верить Кенту Беку, ровно как нет и причин верить безоговорочно. Очевидно, что шаг Майкрософта к MSF это не “младенческий пафос” МЫ ВСЕХ КРУЧЕ, а исключительно результат анализа текущего контекста развития компании. И кто они сейчас мы все знаем
, но с недавних пор это самостоятельная команда web-разработчиков.
Также я не оговорился, это был именно RUP. C MSF все просто - достаточно большой и сложный проект. Поэтому можно наблюдать совпадение как по основным принципам/концепциям, так и по модели процессов/управления рисками.
Что касается Agile, то людей не столь заботит его классификация, сколь степень его адекватности в проектах реверсивной инженерии в условиях продолжительных исследований и минимума информации на старте.
Проекты есть большие и продолжительные, есть разовые и маленькие, а есть те, информацию о которых компания не в праве разглашать в соответствии с соглашением.
Тем не менее, основными требованиями являются C, С++ или .NET.
- разработчики драйверов. Это достаточно большой процент сотрудников компании. Проекты требуют знаний архитектуры ядра Microsoft Windows
- .NET разработчики. Его актуальность все растет.
- разработчики под девайсы. Моб. телефоны, смартфоны, кпк. Также занимаются разработкой ПО для коммуникации. Всячески приветствуется опыт разработки под Symbian, WinMobile/WinCE, Palm.
- раньше они прятались по углам
- есть разработчики, специалисты по сетевой безопасности. Опыт работы с сетевыми протоколами приветствуется.
- исследователи. Ключевым является опыт работы с IDA Pro. Если умеешь ориентироваться не только в Intel ассемблере - только плюс.
Есть также команда специалистов по качеству, которые собственно и ответственны за качество всего ПО компании.
Unknown, боже, и в туалет самостоятельно сбегать не разрешают?
Шучу конечно, рад за тебя.
Твой “совет по секрету” мне понятен. Искренне. Как сам думаешь, скоро ты начнешь брать и делать все сам и на месте вместо поисков и ожиданий где то?
И все тки поход в туалет через тим лидера и архитектора …
это, SUKA, героически
Но я все равно рад, заходи в гости как нибудь.
@artyom.bondartsov
Меж прочим ты смеешься, а реально помогает. Это называется порядок. Если девелопер придумал какую-нить свою идею, то чтобы внедрить он обычно должен поговорить с архитектором, и как обычно бывает, тот не имеет ничего против. Так что проблем здесь почти никаких. Иначе если девелопер будет делать, что хочет, то будет как в басне “Лебедь, щука и рак”. И, это не отвлеченные размышления, за примерами ходить далеко не надо, вспомни самый большой априоровский проект.
И вообще типичная картина была, когда уходит человек, другие берутся суппортить код, а там такие “чудеса”!
Из опыта скажу, что тщательное коде ревью вскрывает много мелких недостатков кода. Оно реально полезно.