Комментарии 44
Вы скажете, что для рисования структуры БД должен быть системный архитектор? Возможно, но не на уровне задачи на собеседовании. В проекте – да! Но уровень задачи на собеседовании аналитиком должен решаться.
А зачем давать задачу на собеседовании, которую в реальности решать не надо и вообще опыта иметь не нужно в этой области?
Вы же не тим-лида ищете, который еще и за разработку отвечать будет.
Роль чистого РП — анализ требований, переговоры с клиентом, утрясание сроков, тимбилдинг. При чем тут бд?
Я все же придерживаюсь мнения, что РП должен быть «универсальным солдатом» в плане скилла и должен понимать, что и как происходит, а не секретарем-переговорщиком, наделенным властью.
+ 1
Ага, только в какой-то момент это все вырождается в то, что на проекте все заняты всем. Аналитик тестирует, РП пишет требования и руководство пользователя, тестировщики уехали на конференцию, а у разработчиков все в мыле. В итоге если кто-то из команды уходит (и не дай бог это РП), начинается адский ад, потому что на человека были завязаны стопицот процессов и с его уходом все перевернется с ног на голову.
Конечно же лучше РП-секретарь :) Я говорил о том, что РП должен «шарить» и что-то уметь хотя бы на базовом уровне, а не перекладывать бумаги и проводить бесконечные митинги с умным видом. Он должен уметь организовать работу подчиненных максимально эффективным образом, а для этого нужно понимать, что же эти подчиненные всетаки делают. Я не говорил, что РП должен заниматься текущими вопросами, но он должен знать, как они решаются, чтобы они его подчиненными решались, а не сбрасывались на тормозах и запарывались.
Вы не правы!
Это, безусловно, полезно.
Но, вообще говоря, у руководителя проекта нет на это времени.
Если оно всё же есть — вопрос к его эффективности.
По большому счёту, РП отвечает за стоимость, сроки и качество проекта.
Как будет сделано всё остальное — дело экспертов (аналитиков), которые должны быть в команде. Я не про конкретные позиции, а про людей, которые смогут исполнить эту роль.
Это, безусловно, полезно.
Но, вообще говоря, у руководителя проекта нет на это времени.
Если оно всё же есть — вопрос к его эффективности.
По большому счёту, РП отвечает за стоимость, сроки и качество проекта.
Как будет сделано всё остальное — дело экспертов (аналитиков), которые должны быть в команде. Я не про конкретные позиции, а про людей, которые смогут исполнить эту роль.
Я вообще придерживаюсь мнения, что чистые РП ну очень редко где нужны.
Командам нужен сильный тим-лид, у которого одинакого круто прокачаны софт и тех скилы.
Я много раз видел людей на должности РП, выросшие из программистов, и это были мягко выражаясь никудышные технари, навязывающие разработчикам как делать им работу, естественно не самым лучшим способом. Про их код вообще молчу.
Командам нужен сильный тим-лид, у которого одинакого круто прокачаны софт и тех скилы.
Я много раз видел людей на должности РП, выросшие из программистов, и это были мягко выражаясь никудышные технари, навязывающие разработчикам как делать им работу, естественно не самым лучшим способом. Про их код вообще молчу.
Вы имеете в виду «Руководителя разработки», а не «Руководителя проекта» разные должности и разные деньги совершенно.
Руководителю проекта, который в технических вопросах не понимает ничего или около ничего, участник проекта (исполнитель) может впарить все, что угодно. Даже 5-ти кратные сроки на исполнение задач. Потому что РП без знаний НЕ в состоянии правильно оценить сроки. И я уверен опыт того, что я пишу (неоправданное завышение сроков) — знакомо всем, кто был связан с внедрением.
У вас довольно дилетантское понимание о проектном менеджменте.
Почитайте, например, PMBOK, посмотрите, откуда берутся оценки сроков.
И подумайте, откуда берётся завышение сроков и стоимости ;)
Почитайте, например, PMBOK, посмотрите, откуда берутся оценки сроков.
И подумайте, откуда берётся завышение сроков и стоимости ;)
Как будто РП со знаниями в состоянии правильно оценить сроки :) Это целая наука и со знаниями предметки связана постольку-поскольку. Больше связана со знанием методик оценки сроков.
А вот то что с предметными знаниями его будут больше уважать в коллективе и меньше вешать лапшу — это есть. Но нужно ли для этого уметь проектировать БД на лету — большой вопрос.
А вот то что с предметными знаниями его будут больше уважать в коллективе и меньше вешать лапшу — это есть. Но нужно ли для этого уметь проектировать БД на лету — большой вопрос.
Странное впечатение от статьи. Будто умение спроектировать БД — ключевой навык аналитика или руководителя проектов. Ну да, понимать надо, суметь нарисовать простую схему ER по примеру тоже надо. Однако эдак вы действительно найдете человека с хорошим техническим бэкграундом, но без понимания, как надо правильно общаться с заказчиком, какие вопросы задавать, что можно и что нельзя говорить. И прекрасно можно провести «обследование» без навыка рисовать БД: исследовать текущее состояние проекта, понять суть проблемы и пожелания заказчика, все это сформулировать в хороших требования и зафиксировать в том или ином документе.
Умение РП общаться с заказчиком — обязательное требование.
И оно также проверяется на собеседовании. Речь в статье не о том.
Но если Вы мне объясните, как человек, неспособный нарисовать по простому примеру связи таблиц, может провести обследование и выдать приличный результат — буду благодарен.
И оно также проверяется на собеседовании. Речь в статье не о том.
Но если Вы мне объясните, как человек, неспособный нарисовать по простому примеру связи таблиц, может провести обследование и выдать приличный результат — буду благодарен.
Я вас понял. Вы просто используете эту задачу как простую проверку на профпригодность. Допустим, более-менее смышленный человек покурит немного пример, схватит принцип и сваяет удовлетворительный результат. Большинство, как в принципе и ожидалось, будут сидет и хлопать глазами. С аналитиками всегда так, либо он не может БД, либо знает только ГОСТ, либо у них в конторе под аналитиком понимали кого-то другого. Объяснять тут особо нечего. Ищите просто хорошего человека, который пусть не сделаеть блестящую диаграмму, но за неделю въедет, как это делается у вас и какие типовые решения есть. Если специфика ваших проектов сильно завязана на структуру баз данных, то можно вытащить в аналитики кого-то из своих кто в теме.
Спаибо за совет…
Вывод: постоянная практика специалиста ТП(админа) позволяет держать мозги в тонусе и решать проблемы здесь и сейчас (надо нарисовать, нарисуем), опираясь на свой трудовой опыт.
Прослойка менеджмента (РП) частеньно оторвана от рабочих процессов и все нагрузка для мозга сводится к бюрократии, отчетам и рассылке тасков, практического опыта, чаще всего, не имеют вовсе.
Занавес.
Прослойка менеджмента (РП) частеньно оторвана от рабочих процессов и все нагрузка для мозга сводится к бюрократии, отчетам и рассылке тасков, практического опыта, чаще всего, не имеют вовсе.
Занавес.
Нам такие РП не нужны. Это лишняя финансовая нагрузка на проект и клиента.
Если вам нужен «боевой РП», то повышайте кого-то из рядов тех. спецов, кто показывает задатки для этого. На стороне «бойца» найдете врятли. Вот у меня у товарища девушка РП. ичо? Она знает много умных слов по-английски (речь засорена ппц), занимается веб-разработкой, но не может толком сформулировать даже зачем ей нужен очередной человек (мне сказали найти %%langname%% программера, вот я и ищу!).
Про какую-либо аналитику или связную беседу на тему разработки я молчу. Она же управленец, а не тех. спец :)
Про какую-либо аналитику или связную беседу на тему разработки я молчу. Она же управленец, а не тех. спец :)
И как он будет без собственной технической экспертизы утрясать требования? сроки и пр.?
Тест на проектирование простой БД (а я пишу вообще о рисованиии связи 10 таблиц) показывает способности РП и аналитика вообще мыслить, анализировать.
Напомню, речь веду о малых и средних проектах, где отдельный человек на тимбилдинг слишком дорог.
Тест на проектирование простой БД (а я пишу вообще о рисованиии связи 10 таблиц) показывает способности РП и аналитика вообще мыслить, анализировать.
Напомню, речь веду о малых и средних проектах, где отдельный человек на тимбилдинг слишком дорог.
Сроки дают разработчики. Их может считать и РП при условии, что разработка совсем типовая.
Требования утрясаются путем узнавания use cases пользователей. Технического бэкграунда тут не надо (я не вижу по крайней мере).
Задача на умение проектировать БД проверяет только умение проектировать БД. Если нужно мышление проверить, ну предложите ему поанализировать задачу с крайне расплывчивыми формулировками. Пусть попробует конкретизировать.
Требования утрясаются путем узнавания use cases пользователей. Технического бэкграунда тут не надо (я не вижу по крайней мере).
Задача на умение проектировать БД проверяет только умение проектировать БД. Если нужно мышление проверить, ну предложите ему поанализировать задачу с крайне расплывчивыми формулировками. Пусть попробует конкретизировать.
Город, если не секрет?
Питер.
60-70 для руководителя в Питере это норм?
вот тоже есть какие-то сомнения.
По моему опыту — маловато. Предполагаю, что компания давно на рынке, имеет хороший бэкграунд из госзаказчиков, РП могут получать очень хорошие премии после завершения проекта (от 300К руб. )
Нет. Я бы сказал, от 85, причем ситуация двухлетней давности. После этого не мониторил.
Внедрение это смежная профессия тут нужно и бизнес процессы компании по полочкам разнести, указать где и когда будет выгода от внедрения. То есть хорошо разбираться в менеджменте и отросли. Технический специалист этого сделать не может, его нужно учить. Виноват в этом университет, на западе экономистам и менеджерам преподают азы программирования и базы данных.
Внедрение это проблема всех отраслей, никто толком не знает зачем им внедрять автоматизацию. В гос структурах если что-то и внедряют, то часто просто заставляют этим пользоваться. Хорошо это плохо не важно, помогло или не помогло — не важно. А в частном секторе не редки случае когда покупают программу только, что бы посмотреть, что это такое.
Дайте парочку задач в личные сообщения :)
Внедрение это проблема всех отраслей, никто толком не знает зачем им внедрять автоматизацию. В гос структурах если что-то и внедряют, то часто просто заставляют этим пользоваться. Хорошо это плохо не важно, помогло или не помогло — не важно. А в частном секторе не редки случае когда покупают программу только, что бы посмотреть, что это такое.
Дайте парочку задач в личные сообщения :)
Знаете, если я бы пришёл на собеседовние на позици РП, а меня попросили разработать структуру БД, я бы её сделал, но вы бы получили допрос с пристрастием (не забывайте, это всё-таки СОбеседование, вопросы может задавать и кандидат) и повышение ценника процентов на 20.
Это должно быть указано в требованиях к вакансии и может быть легко проверено по телефону. Очного собеседования для этого не нужно, вы неэффективно тратите своё время и время своих кандидатов. Собственно, хороший менеджер обязан указать вам на это на собеседовании.
И много ещё замечаний по вашей методике и вашему мнению, который вам сейчас напишут.
Это должно быть указано в требованиях к вакансии и может быть легко проверено по телефону. Очного собеседования для этого не нужно, вы неэффективно тратите своё время и время своих кандидатов. Собственно, хороший менеджер обязан указать вам на это на собеседовании.
И много ещё замечаний по вашей методике и вашему мнению, который вам сейчас напишут.
Структура БД — это модель довольно низкого уровня, очень близкая к реализации. Бизнес-аналитики, вообще говоря, не должны её разрабатывать. Они должны уметь «вытягивать» из заказчика информацию об автоматизируемых бизнес-процессах и описывать её в каком-то удобном для дальнейшей разработки виде — обычно в виде юзкейсов или в какой-то нотации (если в компании такая используется). Не забывая при этом о нефункциональной стороне продукта (этим вообще аналитик отличается от «технаря»). Если специалист сразу преобразует бизнес-задачу в структуру БД, то до аналитика он, скорее всего, не дорос: наверняка сосредоточился только на основной функции, и упустил что-то важное, ради чего, собственно, аналитиков и держат.
Конечно, знание принципов устройства баз данных аналитику скорее поможет, чем навредит. Но если вы требуете построения схемы БД на собеседовании, то вы, скорее всего, ограничиваете круг поиска категорией «разработчики, которые переросли разработку». Вам виднее, конечно, какие специалисты вам нужны, но при таком подходе «крупную рыбу» вы можете упустить — человек с нужными вам знаниями и навыками просто к вам не попадёт.
Приглашать разработчика для проверки знаний аналитика в конкретной СУБД — это очень спорный метод. Разработчик по определению знает больше, и обычно его «допрос» будет сосредоточен на деталях, знание или незнание которых на уровне аналитика или РП вообще ни на что не влияет.
Конечно, знание принципов устройства баз данных аналитику скорее поможет, чем навредит. Но если вы требуете построения схемы БД на собеседовании, то вы, скорее всего, ограничиваете круг поиска категорией «разработчики, которые переросли разработку». Вам виднее, конечно, какие специалисты вам нужны, но при таком подходе «крупную рыбу» вы можете упустить — человек с нужными вам знаниями и навыками просто к вам не попадёт.
Приглашать разработчика для проверки знаний аналитика в конкретной СУБД — это очень спорный метод. Разработчик по определению знает больше, и обычно его «допрос» будет сосредоточен на деталях, знание или незнание которых на уровне аналитика или РП вообще ни на что не влияет.
А можно увидеть что было написано в тексте вакансии — в «требованиях» и в «обязанностях?
Для того, чтобы понимать прав я или нет, надо принимать во внимание стоимость наших проектов, которую я не хочу обсуждать, клиентов и многое другое.
Если кто-то сидит на нефтянке или госструктурах, готовых оплачивать кучу народу в проекте, это не значит, что такая схема возможна и у меня.
Если кто-то сидит на нефтянке или госструктурах, готовых оплачивать кучу народу в проекте, это не значит, что такая схема возможна и у меня.
За последние несколько месяцев прособеседовал человек 50-60 на вакансии аналитиков (в Москве). Понимаю, что уровень з/п в Питере не москвский, но серьезно сомневаюсь, что хороший аналитик с адекватным опытом пойдет работать за 60к. Возможно, отсюда и описанные выше проблемы.
Плюс добавьте сюда, что у вас — явно выраженный акцент на проектировании БД. Для аналитика это полезный скилл, но не всегда строго обязательный (все очень сильно зависит от задач и процессов предыдущих работодателей). Базовые представления о реляционных СУБД — это must have. Спроектировать в условиях стресса без подготовки базу из 10+ таблиц для среднестатистического аналитика- уже скорее nice to have. А перфекционизм — очень коварная штука
Плюс добавьте сюда, что у вас — явно выраженный акцент на проектировании БД. Для аналитика это полезный скилл, но не всегда строго обязательный (все очень сильно зависит от задач и процессов предыдущих работодателей). Базовые представления о реляционных СУБД — это must have. Спроектировать в условиях стресса без подготовки базу из 10+ таблиц для среднестатистического аналитика- уже скорее nice to have. А перфекционизм — очень коварная штука
Крайне редко где аналитик должен рисовать структуры БД. Это задача стороны реализации — разработчика или архитектора. Обычно он должен уметь отделять главное от второстепенного и не позволять продукту расползаться по швам при наращивании функционала + осуществлять перевод между бизнес-языком и языком разработки.
Поднял з.п. до «от 75 тыс.» посмотрим, что приплывет.
Лучшие и полезнейшие нашей компании сотрудники, если смотреть историю, могли без проблем решить задачу с БД.
Не убедит меня никто, что работая в IT, можно не уметь нарисовать 10 таблиц.
Лучшие и полезнейшие нашей компании сотрудники, если смотреть историю, могли без проблем решить задачу с БД.
Не убедит меня никто, что работая в IT, можно не уметь нарисовать 10 таблиц.
1. С таким же успехом они все могли делать по утрам зарядку.
2. Тут вроде особо никто и не убеждает. У всех разный опыт. И каждый имеет право наступать на грабли столько, сколько пожелает.
2. Тут вроде особо никто и не убеждает. У всех разный опыт. И каждый имеет право наступать на грабли столько, сколько пожелает.
Я вот нарисовать схему — нарисую, и как DBA что-нибудь расскажу, и как программер на многих языках прособеседуюсь, но увидев в вакансии на PM технические требования, проигнорирую ее. Чувствуется подвох, как попытка мотивации разработчика позицией.
Может человек базу монгодб на 10 серверов спроектировал, а вы ему таблицы суете.
p.s. На правах шутки. :)
p.s. На правах шутки. :)
Правда в том, что проектирование баз данных — это ни разу не бизнес-анализ. Бизнес-анализ — это ни разу не проектирование баз данных. Можно успешно заниматься обследованиями, зная о базах данных только то, что «они есть, и из них можно получить выгрузки у админов».
Пример: производственному холдингу нужно пересчитать точку перезаказа и оптимизировать схему поставок сырья и полуфабрикатов. Это бизнес-задача. Она требует обследования бизнеса, серьезнейшего анализа данных (в MS Excel), и от баз данных нужны только выгрузки — информация по заводам, складским терминалам и т.д.
Я не соглашусь с тем, что люди, решающие такие задачи — это «офисный балласт».
Вам точно нужны бизнес-аналитики, а не аналитики требований, системные технологи или, прости Господи, конфигурасты?
Пример: производственному холдингу нужно пересчитать точку перезаказа и оптимизировать схему поставок сырья и полуфабрикатов. Это бизнес-задача. Она требует обследования бизнеса, серьезнейшего анализа данных (в MS Excel), и от баз данных нужны только выгрузки — информация по заводам, складским терминалам и т.д.
Я не соглашусь с тем, что люди, решающие такие задачи — это «офисный балласт».
Вам точно нужны бизнес-аналитики, а не аналитики требований, системные технологи или, прости Господи, конфигурасты?
Если ваши сотрудники легко могут решить данную задачу и вам требуется именно такой РП, зачем набирать людей на эту должность, вырастите их из своих сотрудников.
Извините, конечно, за мои 5 копеек, но РП с пониманием БД и умением взглянуть на задачу «как разработчик»,
да еще и умением общаться с клиентом + писать отчуждаемое ТЗ — это либо руководитесь собственной команды/студии
либо специалист с ЗП сильно превышающей ваше предложение, дополнительно замотивированный % от прибыли.
Очень интересно было бы узнать как у вас в итоге получится найти такого человека, обязательно напишите.
Я бы сама с удовольствием нашла себе такую замену :)
да еще и умением общаться с клиентом + писать отчуждаемое ТЗ — это либо руководитесь собственной команды/студии
либо специалист с ЗП сильно превышающей ваше предложение, дополнительно замотивированный % от прибыли.
Очень интересно было бы узнать как у вас в итоге получится найти такого человека, обязательно напишите.
Я бы сама с удовольствием нашла себе такую замену :)
Всем огромное спасибо за комментарии! Они оказались для меня очень полезными и я обдумываю их по вечерам во внерабочее время [без сарказма].
Ну и давайте все-таки придем к соглашению, что не все меряют деньги за пределами МКАД.
Ну и давайте все-таки придем к соглашению, что не все меряют деньги за пределами МКАД.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рынок аналитиков и руководителей проектов