Форум Сообщества Аналитиков
Обсуждения => Идеи и мозговой штурм => Тема начата: Юрий Булуй от 11 Сентября 2008, 12:59:25
-
На сайте Когнитивных технологий объявление ... нужен техпис в департамент документирования ...
Получается, что для разработки Help очень неплохо знать UML :-), а для написания ТЗ по ГОСТ 19 или 34 нужно уметь литературно редактировать текст??? Ниже оригинал объявления ...
Департамент документирования
Позиция: Технический писатель
Занятость: полная
График работы: относительно свободный (в сумме - 40 часов в неделю).
Должностные обязанности: Разработка эксплуатационной и проектной документации, инструкций, функциональных и технологических описаний, создание Help-систем, литературное редактирование текста.
Требования к соискателям:
пол: м/ж
возраст: 22-55
образование: высшее
умение анализировать предметную область и стоящие перед пользователем задачи, способность ориентироваться в разрабатываемом программном обеспечении;
хороший письменный русский язык и умение связно излагать мысли на бумаге;
знание ПК: уровень квалифицированного пользователя
Опыт работы по схожей специальности: необязателен
Приветствуется обладание следующими навыками:
Знание и умение разрабатывать документы по ГОСТ 19 (ЕСПД) и ГОСТ 34 (АС).
Участие в разработке программного обеспечения (в качестве программиста, тестировщика или бизнес-аналитика);
Умение составлять схемы и диаграммы (UML, IDEF).
Оплата в зависимости от результатов собеседования.
-
Ха. Мои директора озаботились поиском ещё одного специалиста. Есть у нас один товарищ, опытный и технически грамотный, который примерно год назад вполне созрел для выполнения роли аналитика, начал в ней работать и к ней привыкать. Но его срочно "перебросили" на тех. поддержку других проектов (грамотных и исполнительных людей всегда не хватает).
В ответ на моё бурное возмущение пообещали найти ещё одного человека. И вот начали искать.
Выложили вакансию, в которой написано "специалист по тестированию и технической поддержке". Слово "аналитик" не вопринимают в принципе. Мне говорят: приходят резюме - давай, проводи собеседования.
Посылаю их в пешее эротическое путешествие - обижаются, говорят: ты же сам говорил, что человек нужен! Мои заявления "это не мне, а вам человек нужен - а мне просто верните того, который был год назад" игнорируют. Кто же тогда в тех проектах дырки заткнёт?
И дело тут не в их тупости (они совсем даже не тупые, а вполне разумные и рациональные), а в принципиальном конфликте интересов и отсутствии каких-либо долгосрочных планов развития. Людям, увлечённо занимающимся текущими продажами, не нужно ни качество (точнее, нужно только на словах), ни нормальный процесс разработки. Им важно как можно больше продать, но так, чтобы их потом как можно меньше беспокоили. И для них наиболее очевидный выход: нанять человека на "техническую поддержку", ко всем бочкам затычку, чтобы замкнуть на него все запросы окученных клиентов, а самим заняться поиском новых. "Перестанет этот справляться - ещё одного наймём."
-
Ну, вполне логично ... пока можно продавать и так, зачем вкладываться? Типичная философия временщиков :-).
-
Ну, вполне логично ... пока можно продавать и так, зачем вкладываться? Типичная философия временщиков :-).
Можно, конечно, обозвать их и временщиками. Но это было бы несправедливо. Тут уже дело, как мне сейчас представляется, в философии самой компании. Компания производит оборудование (чего уж там скрывать, POS-терминалы) - реальные вещи, на которые есть реальный спрос, которые можно подержать в руках, объёмы продаж которых легко измерять и контролировать. "Продуктом" считается конкретная красиво упакованная железяка. Для неё разработан дизайн, закуплены компоненты, пройдены дорогостоящие сертификации, работают два сборочных завода, а наш филиал создан именно для того, чтобы эти железяки продавать. Есть ежегодный план продаж, который спускается из головного офиса.
А процесс разработки софта для этих железяк рассматривается как вспомогательный. То есть раз уж без софта они никому не нужны - приходится нанимать программистов. Программисты - это понятно, они программы программируют. А всякие там тестировщики, аналитики и прочие архитекторы - это просто непонятные и лишние затраты.
То есть баги случаются, это понятно, с этим никто не спорит. Так давайте тогда создадим нечто, называемое технической поддержкой, пусть они собирают запросы клиентов, а программисты пусть эти баги исправляют. А уж в свободное от технической поддержки время (или, как раньше говаривал мой директор, пока не я стал буквально бросаться в него тяжёлыми предметами, "в фоновом режиме") пусть эти же люди занимаются тестированием или там аналитикой всякой.
-
Юрий, как ни странно в данном случае это не "каша" в голове работодателя. Если когнитивные технологии не согласны отдавать "проект" бизнес-аналитикам из дочерней компании они НАЗНАЧАЮТ бизнес-аналитиками всех кто свободен на данный момент (программисты, технические писатели).
В данном случае, компании видимо потребовался специалист широкого профиля, которого для начала планируют использовать как технического писателя.
-
У нас такие объявления не редкость :) Не удивительно если при собеседовании спросят о наличии знаний администрирования, тестирования, а в добавок "нет ли случайно опыта в управлении проектами". Не хочут работадатели оплачивать работу нескольких специалистов, лучше влять спеца "широкого профиля" и платить одну з.п. Грустно...
В данном случае, компании видимо потребовался специалист широкого профиля, которого для начала планируют использовать как технического писателя.
А в последствии навесить на этого спеца все, что только возможно, да еще в рамках того же оклада. Ситуация знакомая.
-
При оформлении на последнее место работы мне дали заполнить анкету с вопросами для сист. админа. Я долго отказывался ее заполнять, но аргументация HR меня сразила - а у нас нет анкеты для сист. аналитика, поэтому заполняйте эту :) После этого пришлось писать ответы по приколу, например, на вопрос - Какой дисковый массив подходит больше для ПК, почтового, файлового и БД сервера, написал - маленький, средний, большой, огромный :)
Хорошо я с ними не столкнулся на этапе собеседования, а то бы не прошел :)
-
Юрий, как ни странно в данном случае это не "каша" в голове работодателя. Если когнитивные технологии не согласны отдавать "проект" бизнес-аналитикам из дочерней компании они НАЗНАЧАЮТ бизнес-аналитиками всех кто свободен на данный момент (программисты, технические писатели).
В данном случае, компании видимо потребовался специалист широкого профиля, которого для начала планируют использовать как технического писателя.
Нужно быть ОЧЕНЬ талантливым человеком, чтобы на профессиональном уровне сочетать все требуемые в данной вакансии skills. Не разу не встречал в своей жизни человека (в корпоративной среде), который бы и на UML проектировал и при этом еще и Help писал одинаково успешно... А уж ТЗ литературным языком ... это просто перл. Как раз в ТЗ чем меньше "литературного подхода", тем лучше -- т.к. основное назначение ТЗ это краткое и четкое изложение ТРЕБОВАНИЙ, а не "Война и Мир" c лирическими отступлениями ...
-
Нужно быть ОЧЕНЬ талантливым человеком, чтобы на профессиональном уровне сочетать все требуемые в данной вакансии skills. ... который бы и на UML проектировал и при этом еще и Help писал одинаково успешно...
Ой, это вы не обо мне тут говорите ::)
-
Эд, ты несомненно талантливый, кто спорит .... но ты не совсем в "корпоративной среде" :-)
-
Эд, ты несомненно талантливый, кто спорит .... но ты не совсем в "корпоративной среде" :-)
Юра, а ты себя считаешь вне "корпоративной среды"?
-
Когда проходила собеседование на предыдущей работе от меня требовалось и знание UML, и IDEF и умение грамотно строить мысли и т.д.
Пришла в конторку на неплохой оклад и при этом мои знания вышеозначенных нотаций практически не пригодились - фирма рисовала порталы на SharePointe. Первым делом меня напрягли писать шаблоны всяких документов. Шаблоны сделала весьма подробные и удобные под заказчиков и проекты различных масштабов.
Все закончилось увольнением до конца испытательного срока. Работодатель решил, что вместо меня отлично справится девочка - тех. пис. за 17 тыр в месяц - делов-то по готовым шаблонам писать! Тем более и кризис начался.
-
Все закончилось увольнением до конца испытательного срока. Работодатель решил, что вместо меня отлично справится девочка - тех. пис. за 17 тыр в месяц - делов-то по готовым шаблонам писать! Тем более и кризис начался.
зато Вы приобрели неоценимый опыт - нельзя отдавать всего себя работодателю задешево, нужны гарантии с его стороны. желательно письменные.
и заодно увидели в деле вариант разводки исполнителя. в следующий раз будете уже осмотрительнее.
-
Видимо, за каждым подобным описанием вакансии, где от тех. писателя требуются знания аналитика, а от аналитика навыки управления проектами и т.п. стоит своя грустная история о путаннице в процессах, ограниченных бюджетах или просто о косяках соискателей с завышенной самооценкой... Ну то есть раз многие люди пишут обо всем, о чем хотя бы слышали, то и в вакансии не грех чуть больше требований указать, чтобы балласт отсеять. :)
Другой вопрос, если компания действительно хочет на позицию писателя получить квалифицированного аналитика... Но тут время и отклики соискателей должны поставить все на свои места.
-
Как-то прогуглив требования к PM-мам, я просто пришла в шок, всем нужен эдакий семиделка, который если что и протестить сможет, досконально знать+опыт не мене 5 лет в нескольких языках программирования, и за сисадмина сойдет вдруг чего...
Действительно обидно, что такая каша в голове работодателей :-(
-
Наткнулась еще на одну подобного рода вакансию. Меня сначала это объявление возмутило - они в названии вакансии так и указали "Программист, бизнес аналитик (IT)":
Западная компания, поставщик высококачественного электрооборудования для строительства и промышленности открывает вакансию «Программиста (Бизнес - аналитика)»
Требования к кандидатам:
Высшее профессиональное образование
Опыт работы в сфере информационных технологий не менее 3-х лет
Знание SQL, OLAP
Владение СУБД, системами построения отчетности Reporting Services
Владение принципами работы ERP-систем
Владение основами теории организации
Основные обязанности:
Разработка, построение и внедрение максимально эффективной системы отчетности, отвечающей потребностям пользователей и бизнеса
Сопровождение системы отчетности компании
Моделирование и анализ бизнес-процессов, их оптимизация
Участие в составлении бюджетов компании, анализ проблемных мест в бизнесе, подготовка рекомендаций для принятия управленческих решений
Участие в поддержке ERP-системы iScala
-
Наткнулась еще на одну подобного рода вакансию. Меня сначала это объявление возмутило - они в названии вакансии так и указали "Программист, бизнес аналитик (IT)":
А потом?
-
Потом подумала, что, возможно, они просто не знают, как назвать того, кто им нужен :) Хотя, вот все-таки вопрос: корректно ли от одного и того же специалиста требовать "разработки, построения и внедрения" системы отчетности (и еще большой вопрос, что они под этим понимают - состав формируемых отчетов или реализация в соответствующем инструментальном средстве) и "моделирования и анализ бизнес-процессов, их оптимизации" да еще и участие в составлении бюджетов и т.д.?
Если речь идет именно о разработке состава отчетов, тогда, может, еще не все так плохо. Но почему тогда они написали, что им нужен "программист, бизнес аналитик"?
В общем, у меня наступает когнитивный диссонанс, когда я пытаюсь понять, что эти работодатели имели в виду. :) А было время, когда я объем того, что необходимо знать и уметь, по объявленным вакансиям определяла... ::)
-
Вероятно, они ищут специалиста, который может решить задачу (от начала до конца). И видимо полагают бизнес-аналитик = требования, программист = реализация :)
-
Пусть будет так - "Не судите, да не судимы будете". А вообще, это же почти несовместимые виды деятельности: программирование и выявление требований. Умение программировать (я имею в виду не базовые знания, а досточные для решения большинства возникающих задач), как правило, служит своего рода ограничением при формировании требований - сужу исходя из своих личных наблюдений.
-
Простите, что вклиниваюсь, на протяжении вот уж 5-ти лет, я совмещаю и тех. писателя, и аналитика и поддержку, что на первом месте работы, что на втором. Когда меняла работу, тоже не знала как себя подать, как первого, второго или третьего... но очень многим работодателям требуется все три в одном лице и на одном окладе...
-
Умение программировать ... служит своего рода ограничением при формировании требований
Скорее, не умение программировать, а само положение разработчика. Если специалист, в чьи обязанности входит написание кода, начнет активно выявлять требования - так ему ж и реализовывать их придется. :)
-
На основании того,что видел функции аналитика могут существенно различаться исходя из:
1. Специфики проектов данной компании(коробочный софт,заказной, внедрение решений вендора, собственные разработки в продуктовой организации)
2. Видения руководства, ставившего процесс разработки,внедрения итп
3. Прижимистости работодателя
-
<...>Получается, что для разработки Help очень неплохо знать UML :-), а для написания ТЗ по ГОСТ 19 или 34 нужно уметь литературно редактировать текст??? Ниже оригинал объявления ...<...>
ЕСПД (которую, скорее всего, имели в виду) - это не только ТЗ/ЧТЗ/ЭП/ТП, но и различные руководства. В т.ч. пользователя, администратора, системного программиста, программиста. Содержание у них - IMHO вполне здравое. И чтобы удобоваримо написать такое - нужно иметь порядок в голове и уметь принять сторону пользователя. Или, что страшнее, вжиться в роль администратора, а то и самого программиста. В общем, Станиславский отдыхает :). Так вот, надо рассказать этому пользователю-администратору-программисту, как ему удовлетворить его потребности при помощи существующей, великой, могучей, до конца не познанной системы, созданной, чтобы получить просветления, а не ради удовлетворения земных нужд. Причём лучше описать языком Пришвина и снабдить занимательными цветными картинками а-ля "Мурзилка".
Некоторые системы обладают большой сложностью, естественной и/или наведённой. Чтобы написать руководство по такой системе, нужно обладать высокой квалификацией. В т.ч. побывать в роли пользователя, администратора, разработчика. Что в этом удивительного? Хорошее руководство написать непросто. Особенно если кто-то в жизненном цикле ПО до тех. писателя сделал свою работу... не очень хорошо. Особенно - если системный аналитик и дизайнер UI.
-
Скорее, не умение программировать, а само положение разработчика. Если специалист, в чьи обязанности входит написание кода, начнет активно выявлять требования - так ему ж и реализовывать их придется. :)
Мне не нравятся такого рода постановки вопроса. Так, получается, и аналитик, не заинтересован в выявлении требований, проблем заказчика, задач, требующих решения посредством внедряемого ПО, - ему ж их потом описывать и анализировать придется!
Я сталкивалась с ситуациями, когда разработчики являлись хорошими специалистами в предметной области - исторически так сложилось, что разработчики изначально были, а аналитиков не было. И что же теперь - ни в коем случае не спрашивать мнения разработчиков?
Человек, ответственно относящийся к своей работе и представляющий и понимающий последствия собственной безответсвенности, вряд ли утаит важное требование просто потому, что ему потом его придется реализовывать. :)
-
Я сталкивалась с ситуациями, когда разработчики являлись хорошими специалистами в предметной области - исторически так сложилось, что разработчики изначально были, а аналитиков не было. И что же теперь - ни в коем случае не спрашивать мнения разработчиков?
Agile методы так и работают: выделенных аналитиков, как правило, нет, и выявлением требований занимается вся команда. Для этого вся команда должна видеть общую цель, а не свою частную задачу (даже если я "утаю" сейчас требование, рано или поздно мне всё равно придётся его реализовывать, причём команде это обойдётся, скорее всего, намного дороже).
-
Человек, ответственно относящийся к своей работе и представляющий и понимающий последствия собственной безответсвенности, вряд ли утаит важное требование просто потому, что ему потом его придется реализовывать.
Вы правы. Именно поэтому и не стоит утверждать, что программирование и выявление требований есть несовместимые виды деятельности. Когда программисты разделяют такую точку зрения - проекту на пользу это не идет.
Я сталкивалась с ситуациями, когда разработчики являлись хорошими специалистами в предметной области
Опытный разработчик обычно хорошо разбирается в предметной области.
Agile методы так и работают: выделенных аналитиков, как правило, нет, и выявлением требований занимается вся команда
У всех свои предпочтения складываются... Мне очень импонируют гибкие методологии разработки. По моим наблюдениям, они довольно эффективны, особенно если не пренебрегать фиксацией достигнутых соглашений.