Грубый поиск на позицию конфигурейшн-менеджера только в нью-йорке дал 2895 вакансий: www.indeed.com/...k,-NY-jobs.html . По моим (опять же, грубым) подсчетам из них так или иначе релевантными будут около 20% (~580)
В Украине релевантных вакансий на данный момент (внимание) целых 6! bit.ly/SMrDrx
Думаю, что выводы очевидны :)
а) не все (даже на западе) считают рейтинг на serverfault.com показательным, а вот на сертификат могут обратить внимание.Документальное подтверждение скиллов перед западным работодателем и знания дополнительно на курсах подтянуть по краеугольным темам
и расскажите про по-настоящему хорошие курсы в Киеве
насколько я знаю, курсов подготовки к зарабатыванию рейтинга на serverfault.com не очень много. а если точнее, то вообще нет :)
вывод: ваш комментарий по поводу развития аккаунта на serverfault.com не совсем уместен
Качать ТФС гуру/админа — оно и интересно и круто, но в нашей стране нафиг никому не надо (или я ошибаюсь?)
Не ошибаетесь. Лично я уже 3 года безрезультатно бьюсь в эту стену лбом. Но, по большому счету, не жалею что выбрал этот путь.
Я бы на вашем месте не смотрел не только на TFS, а на управление конфигурациями в целом. Если вы знаете не понаслышке больше чем об одной системе контроля версий и имеете опыт не только windows-администрирования, но и UNIX-скиллы, то шанс быть востребованным, хоть и остается довольно небольшим, но все-таки увеличивается :)
Если интересно подробней узнать об управлении конфигурациями, можно пообщаться в личке.
Лично я считаю, что несмотря на возможные проблемы с заангажированностью это, на самом деле очень хорошая инициатива. В Украине, насколько я знаю, никаких премий в области информационных технологий до сих пор не было. Первый IT awards навряд ли пройдет гладко, т.к. это пилотный проект (хотя всё таки хотелось бы чтобы всё было хорошо), а вот то, насколько регулярными станут последующие события подобного рода, отразит то, насколько зрелой на самом деле является украинская ит-индустрия.
Как я себе представляю, конфигурейшн-менеджеры вырастают из разработчиков. Вместо того, чтобы идти в лиды/пмы, разработчик расширяет свой круг интересов от вопросов персональной продуктивности до вопросов командной продуктивности, параллельно углубляя знания администрирования, проджект-менеджмента, построения процессов и архитектуры ПО.
Если тим-лид сфокусирован на видении технической составляющей проекта в целом и влияет на то, как в техническом плане будут реализованы те или иные требования, а проджект-менеджер заботится о бюджете, планировании и стратегических планах проекта, то конфигурейшн-менеджер подсказывает как можно построить работу продуктивней, обеспечив нужный уровень качества и, что самое главное, при этом минимизируя время, в течени которого программный код приложения становится доступным для использования либо в виде рабочего приложения, либо в виде его отдельных рабочих частей.
Есть мнение что конфигурейшн-менеджера проще и эффективней всего вырастить из админа. Но лично я так не считаю. Конфигурешйн-менеджер обязательно должен иметь опыт разработки в команде для того, чтобы не по наслышке знать о проблемах технического плана, которые возникают у команды при активном взаимодействии.
Резюмируя вышеизложенное, могу сказать что конфигурейшн-менеджер — это некоторое среднее связующее звено между тим-лидом, проджект-менеджером, архитектором и qa-лидом. Поэтому на такую роль могут претендовать люди с широким кругозором/технической экспертизой и достаточным опытом разработки в команде.
Линус Торвальдс против GitHub — это всё равно, что пчелы против мёда! :)
Как вы считаете, на каких уровнях еще не поздно повернуть назад?
Я верю в то, что на любом из этапов можно повернуть назад при наличии достаточно профессиональной авторитетной третьей стороны (фасилитатора), которая помогла бы конфликт разрешить. Также я верю что всегда у одной из конфликтующих сторон есть внутренняя «потайная дверца» (с ней же — ключ к мотивации конфликт разрешить), открыв которую можно повернуть диалог в конструктивное русло. Но это, опять же при наличии «третьей стороны» и условии наличия еще одного самого важного ресурса — времени. Обратный путь нелегок, болезнен и в зависимости от степени конструктивности и усилий конфликтующих сторон может надолго затянуться.
Есть уровни, на котором конфликт можно разве что похоронить, но разрешить уже невозможно.
Это не совсем с уровнями связано. Это как болезни — есть излечимые легко, есть сложно излечимые (но все таки излечимые), есть неизлечимые. И это зависит от уровня квалифицированности врача, а также уровня медицины в целом.
Буквально сегодня опубликовал запись в своем блоге о том, как планировался и проводился мой тренинг. Возможно будет интересно ознакомиться (осторожно, много букв): alt-ern.livejournal.com/20471.html
Спасибо. Ваши идеи я теперь буду использовать для того, чтобы отбиваться от «толпы», можно? :)
В том то и дело — у человека есть статус, которым он может воспользоваться как угодно в рамках той или иной компании. Возможно не всем людям со статусом это интересно, но, в любом случае, такая возможность многого стоит.
Сори, исправил. Это был не Кнут и не research fellow, а Буч и IBM fellow :)
Как раз в разрезе поднятых вопросов (которые, между прочим, очень по существу), сейчас прибежит толпа и будет вам рассказывать о том, что, дескать, архитектор — это роль (с чем я в корне не согласен), а не позиция! Ведь разработка архитектуры системы — это эпизодическая задача, возникающая на начальной стадии проекта и отнимает ~5% вовлеченных ресурсов. Готовы вы дать толпе отпор?
Еще есть Fellow (как IBM Fellow Grady Booch, например). Лично для меня круче такой роли ничего быть не может.
И что всё-таки надо что б технарю попасть на такую позицию? В какую сторону делать первый шаг?
Наверное обрести soft skills, которых недостаточно для people management, но достаточных для донесения своей позиции, организации и фасилитации технических обсуждений с целью выработки решения, умелой аргументации/критики предложенных решений и в последствии отстаивания архитектурных решений на разных уровнях.
какая одна из высоких позиций в IT-компаниях все еще непосредственно связана с решением технических задач?
Chief Software Engineer например
Архитектура — это структура вычислительной системы, которая включает программные компоненты, внешние свойства этих компонентов, а также отношения между ними [Software Engineering Institute]Архитектура — это все решения, которые, сделав однажды, затем трудно изменить [Grady Booch, Martin Fowler]
Кроме всего прочего, архитектура — это набор соглашений (conventions), которые участники проекта либо принимают и следуют им, либо не участвуют в проекте вовсе.
Контроль целостности архитектруры и атрибутов качества системы (quality attributes — e.g. scalability, maintainability, etc)
Стоит отметить, что помимо scalability и maintainability само наличие архитектуры в разрабатываемом решении — это очень важная составляющая, напрямую влияющая на качество результата.
Проблема в том, что бонусы не пахнут. За переход внутри компании бонусы никто не дает.
кто-то из разработчиковпро разработчиков согласен, но ...
или тестировщиковНикогда не приходилось наблюдать как тестировщик настраивает работу системы контроля версий, пишет билд-скрипты, настраивает работу continuous integration сервера и следит за зависимостями.
Кроме того, разве UI developer, UX developer и тому подобные «позиции», которые присутствуют на диаграмме — это не такие же роли, которые ситуативно выполняются в большинстве команд на интуитивном уровне? Что уж говорить, если очень часто project manager — это скорее роль, нежели позиция? Поэтому мне кажется, что ваш аргумент не очень состоятелен.
Как по мне, следующих обязанностей/функций конфигурейшн менеджеру вполне достаточно для того, чтобы считать это уже позицией, а не ролью:
Я ни в коем случае не собираюсь вас переубеждать, просто по каким-то причинам я очень часто сталкиваюсь с сопротивлением вроде вашего. Дескать, configuration management — это так, эпизодическая никому не нужная функция в то время, как это уже давно (на западе по-крайней мере) стало отдельной инженерной дисциплиной.
По прошествии довольно большого количества времени после события (многое уже забылось) могу сказать, что мне больше всего запомнился рассказ Игоря Паламарчука о должной роли образования в it-компании. Я уже не помню на какой конкретно вопрос Игорь отвечал (да и детали излагаемого конечно же забылись), но ощущение полного резонанса с излагаемыми Игорем идеями лично у меня (оценивая реакцию присутствующих, можно сказать что не только у меня) присутствовало на протяжении всего времени рассказа.
В частности, очень запомнилась одна важная ключевая особенность отношения к образованию в некоторых западных компаниях. Упомянутая особенность заключалась в том, что ведущие игроки силиконовой долины (насколько я помню, Игорь упоминал Microsoft, Apple и Google) крайне неохотно принимают в ряды топ-менеджеров тех людей, которые не проработали хотя бы
По-моему, эта идея является одной из самых важных среди тех, которые были выражены на встрече, так как подобное отношение к образованию (или же его отсутствие) кардинально влияет на состояние дел с обучением в ИТ и на то, какую роль играет образование при попытке компании быть успешной. Почему это так важно? Вот несколько причин:
Если будут подобные встречи в будущем, очень хотелось бы, чтобы они проходили именно в таком конструктивном формате, которого старался придерживаться Игорь.
Мероприятие в целом понравилось. Спасибо Юлие Тупчий за организацию, а также долгожданную возможность встретиться, познакомиться и пообщаться с множеством замечательных людей.
протухла ссылка(
<grammarnazimode>исследование интересное и в целом полезное. но к автору очень большая просьба — потрудитесь исправить грамматические ошибки. уверен что после этого результаты вашего кропотливого труда станут чуть более весомыми.</grammarnazimode>