Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 82
Миллионы «ничего». Как, впрочем, и ожидалось. Кто-то за составление этого получает зарплату, а бизнес, который потом из-за этой ахинеи страдать будет, налогами эти зарплаты оплачивает.
1. Что значит «ничего»? Есть какие-то содержательные комментарии к тексту документа?
2. Бизнес как раз и выступил разработчиком профстандарта, как видно по названиям компаний.
Я с 2011-го года занимаюсь популяризацией профессии и дисциплины управления продуктами в России. В частности, организовывал Product Camp Moscow 2011, помогал в организации последующих: productcamp.ru
В 2013-м году, когда я вписался к АП КИТу организовывать работу по созданию профстандарта системного аналитика, узнал, что МинКомСвязи, помимо прочих 30 ИТ-профстандартов, заказал зачем-то МинТруда стандарт менеджера ИТ-продуктов (хотя профессия очень молодая и ещё не устоялась даже на западе).
У меня был вариант ничего не делать и дождаться того, чтобы конкурс на разработку профстандарта выиграл какой-нибудь региональный вуз, далёкий от производства и бизнеса или вообще компания, делающая торговых интернет-роботом. Например, последний случай произошёл с профстандартом дизайнера интерфейсов в прошлом году — конкурс был выигран, но никакого стандарта сделано не было.
Но я решил «возглавить безобразие», т.к. я видел, что на рынке есть полная неразбериха с тем, что это за профессия, чем занимается. Я сам сталкивался с этим неоднократно на собеседованиях в 2012-2013-м годах. Я посчитал, что это хороший шанс начать формировать публичное понимание профессии, необходимых компетенций, уровней квалификации.
Мы с АП КИТом вписались в конкурс, я через открытые каналы собрал рабочую группу. Мы выиграли конкурс с многократным падением по цене — первоначальная сумма каждого конкурса на профстандарты 600 тр, мы выиграли с предложением 78 тр.
Затем, согласно условиям контракта, нужно было за 3 месяца разработать профстандарт и пояснительную записку к нему, привлекая не менее 20 организаций и 100 специалистов. Вы правда считаете, что 78 тр минус налоги — это прям пипец зарплата за такую работу?
Отдельно ниже напишу по поводу «бизнес страдает».
2. Бизнес как раз и выступил разработчиком профстандарта, как видно по названиям компаний.
Я с 2011-го года занимаюсь популяризацией профессии и дисциплины управления продуктами в России. В частности, организовывал Product Camp Moscow 2011, помогал в организации последующих: productcamp.ru
В 2013-м году, когда я вписался к АП КИТу организовывать работу по созданию профстандарта системного аналитика, узнал, что МинКомСвязи, помимо прочих 30 ИТ-профстандартов, заказал зачем-то МинТруда стандарт менеджера ИТ-продуктов (хотя профессия очень молодая и ещё не устоялась даже на западе).
У меня был вариант ничего не делать и дождаться того, чтобы конкурс на разработку профстандарта выиграл какой-нибудь региональный вуз, далёкий от производства и бизнеса или вообще компания, делающая торговых интернет-роботом. Например, последний случай произошёл с профстандартом дизайнера интерфейсов в прошлом году — конкурс был выигран, но никакого стандарта сделано не было.
Но я решил «возглавить безобразие», т.к. я видел, что на рынке есть полная неразбериха с тем, что это за профессия, чем занимается. Я сам сталкивался с этим неоднократно на собеседованиях в 2012-2013-м годах. Я посчитал, что это хороший шанс начать формировать публичное понимание профессии, необходимых компетенций, уровней квалификации.
Мы с АП КИТом вписались в конкурс, я через открытые каналы собрал рабочую группу. Мы выиграли конкурс с многократным падением по цене — первоначальная сумма каждого конкурса на профстандарты 600 тр, мы выиграли с предложением 78 тр.
Затем, согласно условиям контракта, нужно было за 3 месяца разработать профстандарт и пояснительную записку к нему, привлекая не менее 20 организаций и 100 специалистов. Вы правда считаете, что 78 тр минус налоги — это прям пипец зарплата за такую работу?
Отдельно ниже напишу по поводу «бизнес страдает».
менеджер ИТ-продуктов… профессия очень молодая и ещё не устоялась даже на западе.
Не знаю, как в прошлом веке, но с начала 21 века в западных компаниях это профессия точно существовала и была прекрасно формализована. Однако, менеджер продуктов в понимании западного работодателя это совсем не «коммерсант» и не «самостоятельная боевая единица», прикипевшая к продукту, как это представлено в «стандарте».
Если коротко:
Менеджер продуктов это руководитель работ по поддержке всех (или же только определенных) фаз жизненного цикла продуктов (или одного конкретного продукта). Ему подотчетны различные команды непосредственно осуществляющие выполнение этих работ. Он непосредственно сам или через подотчетных менеджеров команд администрирует работы, связанные с продуктами, за которые он отвечает. Менеджер продуктов, по-сути, является административно-техническим «исполнителем желаний», поступающих от специалистов по маркетингу. Как правило, он работает на основании внутреннего корпоративного документа типа Market Requirements Document, который для конкретного продукта устанавливает соглашение между командами маркетинга и техническими командами. Другими документами, определяющими его работу является разработанные и утвержденные в компании планы жизненных циклов конкретных продуктов.
Вот коротко как-то так.
Помню, я действительно испытал шок, когда открыл для себя, что во многих(!) российских ИТ компаниях Менеджер проекта\продукта это настоящий кудесник-камикадзе, который, не обладая административными полномочиями над исполнителями, отвечает за выполнение проекта или счастливую жизнь продукта.
Это тогда подорвало мою веру:
- в непогрешимость IDEF0 — у нас процессы работают даже когда ресурсы\механизмы неподконтрольны.
- в необходимость иметь в организации строгую иерархию и единоначалие — «прибегает левый менеджер продукта к исполнителю и в пожарном порядке ориентирует его на выполнение срочной работы, прибегает правый менеджер… и понеслось...».
«с начала 21 века в западных компаниях это профессия точно существовала и была прекрасно формализован»
Почему вы так считаете? Какие этому свидетельства? Когда появился Product Management BOK?
Например, Марти Кэган, один из евангелистов професии и автор книги «Inspired: How to create Products Customers Love» на конференции Mind The Product 2012-года говорил, что ещё несколько лет назад в индустрии этой профеcсии толком не знали.
Ваше короткое описание руководителя работ по поддержке ЖЦ фактически описывает руководителя ПРОГРАММЫ, а не продукта. Важное отличие — руководитель продукта выступает заказчиком результата, определяет его свойства как продукта. В случае руководителя программы это совсем не обязательно. Более того, руководители программ прекрасно работают как в контексте внутренней, так и заказной разработки (а не только продуктовой).
Функция руководителя программы у менеджера продукта может быть, а может не быть. А вот функция заказчика для него обязательна.
Схема MRD — PRD — FRS — HLD с передачей решений по цепочке уже устарела. Посмотрите на причины появления методик Lean Startup и Customer Development.
Сейчас маркетолог в связке с менеджером продукта помогает последнему организовать продвижение продукта на рынок и, в некоторых случаях, выполнять маркетинговые исследования.
Сейчас на рынке есть несколько вариаций толкования того, кто такой менеджер продукта, в зависимости от компании:
1. Мини-CEO
2. Предприниматель на службе у предпринимателя
3. Руководитель бизнес-направления, который имеет бюджет и людей и может ими полностью распоряжаться
4. Внутренний заказчик, который отвечает за заказ правильного продукта, чтобы тот стал успешным на рынке, но не имеет ни бюджета, ни подчинённых
5. Внутренний заказчик, — // -, который не имеет подчинённых, но имеет бюджет
6. Руководитель программы
7. Агрегатор и фасилитатор запросов заинтересованных лиц (Product owner)
Мне лично ближе трактовка 2/3 (http://www.slideshare.net/maieutic/ss-14069205), но 1, 4, 5 тоже имеют право на жизнь, как мне кажется.
Почему вы так считаете? Какие этому свидетельства? Когда появился Product Management BOK?
Например, Марти Кэган, один из евангелистов професии и автор книги «Inspired: How to create Products Customers Love» на конференции Mind The Product 2012-года говорил, что ещё несколько лет назад в индустрии этой профеcсии толком не знали.
Ваше короткое описание руководителя работ по поддержке ЖЦ фактически описывает руководителя ПРОГРАММЫ, а не продукта. Важное отличие — руководитель продукта выступает заказчиком результата, определяет его свойства как продукта. В случае руководителя программы это совсем не обязательно. Более того, руководители программ прекрасно работают как в контексте внутренней, так и заказной разработки (а не только продуктовой).
Функция руководителя программы у менеджера продукта может быть, а может не быть. А вот функция заказчика для него обязательна.
Схема MRD — PRD — FRS — HLD с передачей решений по цепочке уже устарела. Посмотрите на причины появления методик Lean Startup и Customer Development.
Сейчас маркетолог в связке с менеджером продукта помогает последнему организовать продвижение продукта на рынок и, в некоторых случаях, выполнять маркетинговые исследования.
Сейчас на рынке есть несколько вариаций толкования того, кто такой менеджер продукта, в зависимости от компании:
1. Мини-CEO
2. Предприниматель на службе у предпринимателя
3. Руководитель бизнес-направления, который имеет бюджет и людей и может ими полностью распоряжаться
4. Внутренний заказчик, который отвечает за заказ правильного продукта, чтобы тот стал успешным на рынке, но не имеет ни бюджета, ни подчинённых
5. Внутренний заказчик, — // -, который не имеет подчинённых, но имеет бюджет
6. Руководитель программы
7. Агрегатор и фасилитатор запросов заинтересованных лиц (Product owner)
Мне лично ближе трактовка 2/3 (http://www.slideshare.net/maieutic/ss-14069205), но 1, 4, 5 тоже имеют право на жизнь, как мне кажется.
3. По поводу «бизнес страдает».
По документам МинТруда 2013-го года профстандарты создавались как рекомендательный инструмент для индустрии. Именно так мы их и разрабатывали.
В этом году пошли волны со стороны президента на тему того, чтобы профстандарт учитывался при создании федеральных государственных образовательных стандартов — в этом нет ничего плохого. Именно так бизнес может передать свой «заказ» на подготовку специалистов в вузы (раньше, насколько я понимаю, такого механизма не было свосем).
Под конец этого года градус усилился и появились слухи, что стандарты должны быть не рекомендательными, а обязательными.
Мы, как разработчики, против такого подхода, т.к. его проблемы совершенно понятны.
С другой стороны, макет профстандарта от МинТруда устроен так, что перечень функций, знаний и умений не является законченным тестом и поэтому не даёт однозначного ответа о владении или невладении ими.
Например, написано «уметь создавать планы развития продуктов». Без критериев качества и сроков создания таких планов это просто название деятельности. Поэтому формально план развития продукта может и 10-летний ребёнок написать в стиле «в следующей версии в игре можно будет грабить корованы».
Поэтому обязательность профстандартов (для вузов) именно в текущем виде ничего конкретного не влечёт.
Обязательность профстандартов такого рода для коммерческих организаций — это действительно маразм, если это будет происходить.
По документам МинТруда 2013-го года профстандарты создавались как рекомендательный инструмент для индустрии. Именно так мы их и разрабатывали.
В этом году пошли волны со стороны президента на тему того, чтобы профстандарт учитывался при создании федеральных государственных образовательных стандартов — в этом нет ничего плохого. Именно так бизнес может передать свой «заказ» на подготовку специалистов в вузы (раньше, насколько я понимаю, такого механизма не было свосем).
Под конец этого года градус усилился и появились слухи, что стандарты должны быть не рекомендательными, а обязательными.
Мы, как разработчики, против такого подхода, т.к. его проблемы совершенно понятны.
С другой стороны, макет профстандарта от МинТруда устроен так, что перечень функций, знаний и умений не является законченным тестом и поэтому не даёт однозначного ответа о владении или невладении ими.
Например, написано «уметь создавать планы развития продуктов». Без критериев качества и сроков создания таких планов это просто название деятельности. Поэтому формально план развития продукта может и 10-летний ребёнок написать в стиле «в следующей версии в игре можно будет грабить корованы».
Поэтому обязательность профстандартов (для вузов) именно в текущем виде ничего конкретного не влечёт.
Обязательность профстандартов такого рода для коммерческих организаций — это действительно маразм, если это будет происходить.
Основную идею я понял — это было руководство для ВУЗов по подготовке специалистов. Ну, допустим. Но к чему все эти килограммы ОКАТО, кодов деятельности и прочих вещей, не относящихся ни к профессии, ни к компаниям, которые этих профессионалов нанимают?
Повышение занятости персонала в области бухгалтерского учёта и GR?
Повышение занятости персонала в области бухгалтерского учёта и GR?
ОКАТО там нет.
Указание ОКЗ и ОКВЭД, ЕКС, ОКНПО, ОСКО — это требование макета профстандарта МинТруда.
ОКЗ и ОКВЭД могут быть как минимум полезны для статистического учёта и различения тех профессий, которые требуют обязательного лицензирования и нет. Это может касаться и политик налогообложения и чего угодно.
ЕКС, ОКНПО и ОСКО как раз и нужны для привязки программ подготовки пту, колледжей, техникумов и вузов к стандартам. Чтобы они не отмахивались, например — «мы не менеджера продуктов в области ИТ готовим, а руководителя … или специалиста… поэтому этот стандарт к нам не применим».
Указание ОКЗ и ОКВЭД, ЕКС, ОКНПО, ОСКО — это требование макета профстандарта МинТруда.
ОКЗ и ОКВЭД могут быть как минимум полезны для статистического учёта и различения тех профессий, которые требуют обязательного лицензирования и нет. Это может касаться и политик налогообложения и чего угодно.
ЕКС, ОКНПО и ОСКО как раз и нужны для привязки программ подготовки пту, колледжей, техникумов и вузов к стандартам. Чтобы они не отмахивались, например — «мы не менеджера продуктов в области ИТ готовим, а руководителя … или специалиста… поэтому этот стандарт к нам не применим».
Короче, оно всё не имеет ни малейшего отношения к реальной жизни. Исключительно бюрократами для бюрократов, чтобы от бюрократии не отмахивались.
А вам эти несчастные 10 цифр как-то мешают?
Вы когда либо занимались интеграцией систем? Видели, что такое несогласованные справочники?
Вы когда либо занимались интеграцией систем? Видели, что такое несогласованные справочники?
Я честно этот документ прочитал и не понял, какую боль он решает для компании.
А зачем вы открывали документ, что вами двигало, какие мотивы?
Ваш вопрос конкретно к этому стандарту или ко всей группе ИТ-профстандартов?
apkit.ru/committees/education/meetings/standarts.php
Ваш вопрос конкретно к этому стандарту или ко всей группе ИТ-профстандартов?
apkit.ru/committees/education/meetings/standarts.php
Вероятнее всего, «ко всей группе». Я когда речь про них впервые шла, ожидал некого развёрнутого плана обучения, чему учить, а чему нет.
С детализацией списка алгоритмов на графах с которыми надо познакомить программистов и особенностей работы dwdm для сетевых инженеров.
Вместо этого я увидел тщательно формленную, с миллионом ненужных цифр, воду для бюрократов о том, как играть в бюрократию.
С детализацией списка алгоритмов на графах с которыми надо познакомить программистов и особенностей работы dwdm для сетевых инженеров.
Вместо этого я увидел тщательно формленную, с миллионом ненужных цифр, воду для бюрократов о том, как играть в бюрократию.
Ну вы же понимаете, что «развёрнутый план обучения» и «профессиональный стандарт» — несколько разные вещи?
Профстандарты определяют область деятельности и содержание деятельности профессии, а в каком порядке этой деятельности обучаться — дело соответствующих учебных планов.
Вы знакомы, например, с рекомендациями по преподаванию информатики и программной инженерии? Там подобные тематические планы есть, т.к. это именно образовательные стандарты.
Почему вы называете перечень функций «бюрократией»? Что, по-вашему, границы профессий не важны? Нормально, когда работодатель считает, что архитектор должен управлять проектом?
Миллиона цифр там нет, даже не то что миллиона, а даже сотен. Зачем вы преувеличиваете?
Профстандарты определяют область деятельности и содержание деятельности профессии, а в каком порядке этой деятельности обучаться — дело соответствующих учебных планов.
Вы знакомы, например, с рекомендациями по преподаванию информатики и программной инженерии? Там подобные тематические планы есть, т.к. это именно образовательные стандарты.
Почему вы называете перечень функций «бюрократией»? Что, по-вашему, границы профессий не важны? Нормально, когда работодатель считает, что архитектор должен управлять проектом?
Миллиона цифр там нет, даже не то что миллиона, а даже сотен. Зачем вы преувеличиваете?
Вы знаете, по прошествии какого-то времени в индустрии, я так и не понимаю зачем нужны такие профстандарты, как описываемый выше.
Непонимающий работодатель — это проблема общества только в условиях госплана. В нормальной рыночной экономике — это проблема работодателя и его стейкхолдеров.
Я называю всё это «бюрократией», потому что выполнение этих стандартов или не выполнение не влияет на результат работы айтишников. То есть это стандарты для кого угодно, только не для индустрии.
Непонимающий работодатель — это проблема общества только в условиях госплана. В нормальной рыночной экономике — это проблема работодателя и его стейкхолдеров.
Я называю всё это «бюрократией», потому что выполнение этих стандартов или не выполнение не влияет на результат работы айтишников. То есть это стандарты для кого угодно, только не для индустрии.
Я описывал ниже ситуацию, когда и как мне, как руководителю отдела, пригодились подобные наработки:
habrahabr.ru/post/246583/?reply_to=8199661#comment_8197193
Я ничего не писал про «непонимающего» работодателя, я писал про конфликт представлений, который влечёт за собой потерю времени и денег как со стороны нанимателя, так и со стороны специалиста, например.
Вот работодатели объединились и решили решить свои частные проблемы с помощью отраслевого «табеля о рангах».
habrahabr.ru/post/246583/?reply_to=8199661#comment_8197193
Я ничего не писал про «непонимающего» работодателя, я писал про конфликт представлений, который влечёт за собой потерю времени и денег как со стороны нанимателя, так и со стороны специалиста, например.
Вот работодатели объединились и решили решить свои частные проблемы с помощью отраслевого «табеля о рангах».
Выглядит как задача для управленцев. Допустим, я эту область знаю плохо и особо не лезу. Вот когда лезут в обратную сторону — вот тогда меня это смущает и напрягает. Какой-то дядя потряхивая кипой стандартизированных и водянистых бумаг лезет определять профессиональный уровень сотрудника.
Понятно, что всех идиотов рынок расставит. Но, иногда, он это делает с сильным запозданием.
Понятно, что всех идиотов рынок расставит. Но, иногда, он это делает с сильным запозданием.
Приятно видеть как группа коллег из больших, успешных компаний произвела столько понятный и четкий документ.
п.3.1.2 забавный.
«Необходимые умения: проводить совещания»
«Необходимые умения: проводить совещания»
Мне пункт 3.3.6 больше понравился
«Необходимые умения: убеждать собеседника»
Особенно в контексте планируемой «Должностной инструкции».
«Необходимые умения: убеждать собеседника»
Особенно в контексте планируемой «Должностной инструкции».
Кроме mail.ru и яндекса не знаю ни одной компании.
Интересно, с чего они считают, что все ИТ-менеджеры заняты продажей…
Ну речь судя по всему не об ИТ-менеджерах и не о менеджерах проектов :)
А у нас есть менеджер, который ни продаёт, ни покупает, проектов у него тоже нет.
Работу организует просто.
Работу организует просто.
По ИТ-менеджерам есть несколько других профстандартов:
1. Менеджер по информационным технологиям
2. Руководитель проектов в области информационных технологий
3. Руководитель разработки программного обеспечения
apkit.ru/committees/education/meetings/standarts.php
1. Менеджер по информационным технологиям
2. Руководитель проектов в области информационных технологий
3. Руководитель разработки программного обеспечения
apkit.ru/committees/education/meetings/standarts.php
Сейчас эникещиков будет корежить.
Не читал, зато работал с одним из авторов. Пункт про навык подходить к разработчику и спрашивать «почему не уложился в оценку?» присутствует?
Информация для посетителей сайта:
Виртуальный сервер не существует или временно не функционирует.
Информация для владельцев сайта:
Пожалуйста, свяжитесь со службой технической поддержки:
Поправьте ссылку на стандарт
Мне кажется слова «информационные технологии» тут совсем лишние, всё что написано подойдёт к любым продуктам и к любой индустрии.
Из документа прямо ощутимо повеяло такими вещами как совок, квадратно-гнездовое мышление, waterfall, кровавый энтерпрайз, госструктуры, корпорации, code monkeys, дэдлайны, костыли, пятница, служебная лестница, архаичные технологии, алкоголизм, просрали все полимеры.
Из документа прямо ощутимо повеяло такими вещами как совок, квадратно-гнездовое мышление, waterfall, кровавый энтерпрайз, госструктуры, корпорации, code monkeys, дэдлайны, костыли, пятница, служебная лестница, архаичные технологии, алкоголизм, просрали все полимеры.
Исторически эта профессия в своём современном понимании возникла именно в ИТ-среде. Но со временем стало ясно, что большинство методов применимо и к нецифровым продуктам.
Если нам удастся свои наработки сделать межотраслевыми, это будет здорово, но одно дело договориться с айтишниками (и то эта профессия больше про ИТ-маркетинг и предпринимательство, чем просто про ИТ, от чего многих айтишников коробит пузырями) и совсем другое — со всем рынком. Видели бы вы, как люди мучаются со стандартом учителя :)
А какого документа бы вам хотелось и зачем?
Если нам удастся свои наработки сделать межотраслевыми, это будет здорово, но одно дело договориться с айтишниками (и то эта профессия больше про ИТ-маркетинг и предпринимательство, чем просто про ИТ, от чего многих айтишников коробит пузырями) и совсем другое — со всем рынком. Видели бы вы, как люди мучаются со стандартом учителя :)
А какого документа бы вам хотелось и зачем?
Спасибо за пояснения.
> Должностных инструкций;
> Текстов вакансий;
Думаю что должностные инструкции и тексты вакансий лучше писать человеческим языком, а не формальным.
> Корпоративных профилей компетенций;
> Планов профессионального развития;
> Сертификационных программ и тестов;
> Коммерческих учебных программ;
> Федеральных образовательных программ.
К сожалению мне не приходилось сталкиваться с серьёзным корпоративным миром, где это всё нужно.
Мне пока ближе другой мир где «Корпоративный профиль компетенций» это непонятная фраза,
«План профессионального развития» это список из 10-20 целей, которые появились из реальной практической деятельности и общения с мощными профессионалами, и список из нескольких десятков книг, презентаций, курсов, которые нужны для моих целей, «Сертификационные программы и тесты» ценятся только если они популярные и признанные и не обязательно с официальным сертификатом, например курсы на какой-нибудь курсере, «Коммерческие учебные программы» сделаны не для того чтобы выдать сертификат а для того чтобы научить реально применяемым ощутимым знаниям, а знания даваемые «Федеральными образовательными программами» считаются менее ценными чем bleeding edge в достижениях человечества, который часто меняется чаще чем успевают переводить книги на русский и писать федеральные программы.
> Должностных инструкций;
> Текстов вакансий;
Думаю что должностные инструкции и тексты вакансий лучше писать человеческим языком, а не формальным.
> Корпоративных профилей компетенций;
> Планов профессионального развития;
> Сертификационных программ и тестов;
> Коммерческих учебных программ;
> Федеральных образовательных программ.
К сожалению мне не приходилось сталкиваться с серьёзным корпоративным миром, где это всё нужно.
Мне пока ближе другой мир где «Корпоративный профиль компетенций» это непонятная фраза,
«План профессионального развития» это список из 10-20 целей, которые появились из реальной практической деятельности и общения с мощными профессионалами, и список из нескольких десятков книг, презентаций, курсов, которые нужны для моих целей, «Сертификационные программы и тесты» ценятся только если они популярные и признанные и не обязательно с официальным сертификатом, например курсы на какой-нибудь курсере, «Коммерческие учебные программы» сделаны не для того чтобы выдать сертификат а для того чтобы научить реально применяемым ощутимым знаниям, а знания даваемые «Федеральными образовательными программами» считаются менее ценными чем bleeding edge в достижениях человечества, который часто меняется чаще чем успевают переводить книги на русский и писать федеральные программы.
Думаю что должностные инструкции и тексты вакансий лучше писать человеческим языком, а не формальным.
Вообще-то целью изложения «формальным языком» обычно является повышение однозначности трактовки написанного всеми читателями целевой аудитории (или целевой компьютерной системой).
Или Вы за то, чтобы должностные инструкции и тексты вакансий можно было бы расценивать по принципу «как захочешь»? :-)
Хотя, да, авторов некоторых «формальных» текстов очень хочется попросить изложить свои мысли «человеческим языком».
Но, это чаще возникает совсем не из-за формализма.
По поводу «корпоративного профиля компетенций».
В 2009-2010-м годах я строил отдел системного анализа, и вырастил его с 10 до 30 человек. Среди этих людей были профессионалы с разным опытом, квалификацией и стоимостью на рынке. Было несколько запросов:
1. Люди с разной квалификацией должны иметь разные должности (старший, младший, ведущий)
2. Разница должностей должна быть содержательной — т.е. должно быть чётко понятно, что умеет делать один уровень, что нужно уметь для другого
3. Таким образом, сотрудники смогут строить планы своего профессионального развития по приобретению и развитию конкретных компетенций
4. Компании нужно было ввести тарифную сетку, ввести привзяку оплаты к уровню квалификации, для этого нужны были различимые уровни
Таким образом, мы, внутри отдела, опираясь на наработки АП КИТа 2007-го года разработали профили компетенций и смогли реализовать запросы 1-4. Если вам такие задачи не встречались, это не значит, что их ни у кого нет.
В 2009-2010-м годах я строил отдел системного анализа, и вырастил его с 10 до 30 человек. Среди этих людей были профессионалы с разным опытом, квалификацией и стоимостью на рынке. Было несколько запросов:
1. Люди с разной квалификацией должны иметь разные должности (старший, младший, ведущий)
2. Разница должностей должна быть содержательной — т.е. должно быть чётко понятно, что умеет делать один уровень, что нужно уметь для другого
3. Таким образом, сотрудники смогут строить планы своего профессионального развития по приобретению и развитию конкретных компетенций
4. Компании нужно было ввести тарифную сетку, ввести привзяку оплаты к уровню квалификации, для этого нужны были различимые уровни
Таким образом, мы, внутри отдела, опираясь на наработки АП КИТа 2007-го года разработали профили компетенций и смогли реализовать запросы 1-4. Если вам такие задачи не встречались, это не значит, что их ни у кого нет.
Про коммерческие учебные программы
Рынок так устроен, что в ряде компаний при выборе поставщиков услуг обучения при прочих равных выберут того, который имеет регалии. То, что конкретная учебная программа опирается не только на экспертизу, но и на лучшие отраслевые практики — дополнительный плюс программы. Таковы корпоративные политики и в них есть рациональное зерно.
Таким образом и мы в Школе управления продуктами хотим основываться на признанных соглашениях (а профстандарт именно про это), а не только на своей экспертизе.
Рынок так устроен, что в ряде компаний при выборе поставщиков услуг обучения при прочих равных выберут того, который имеет регалии. То, что конкретная учебная программа опирается не только на экспертизу, но и на лучшие отраслевые практики — дополнительный плюс программы. Таковы корпоративные политики и в них есть рациональное зерно.
Таким образом и мы в Школе управления продуктами хотим основываться на признанных соглашениях (а профстандарт именно про это), а не только на своей экспертизе.
Печальный какой-то этот документ. И кегль 12-тый и шрифт черный, и всё вроде бы согласно Методических рекомендаций, но не могу заставить себя назвать стандартом этот набор околоИТшных слов с опасным коммерческим креном.
Искренне жалею уважаемых авторов, которые с подачи Федора Тимофеевича (автора макета стандарта) и Министерствазащиты трудностей, создали такой изумительный памятник сферического коня в вакууме в элегантной позе «не в контексте нынче я».
Никого не желаю обидеть, просто констатирую факт по уже утвержденному стандарту.
Тем не менее, очень хочется спросить самих авторов документа из компаний со звучными названиями:
И главный вопрос к авторам:
Какие авторитетные труды\материалы\издания\исследования легли в основу этого стандарта?
Ведь без ответов на подобные вопросы абсолютно невозможно определиться со степенью возможного доверия к этому «стандарту».
Вот, к примеру:
Вдруг мы не знаем, а уже таки появились секретные технологии, позволяющие «разрабатывать требования к качеству продукта» в рамках отдельно взятого «Трудового действия».
То есть делать это как-то отдельно от разработки других требований.
И это даже несмотря на то, что к продукту обычно предъявляется многоаспектный комплекс требований, в котором безусловно каждое значимое требование влияет на качество продукта.
Вдруг мы должны уже просто забыть про то, что качество продукта как раз и определяется его возможностями удовлетворить всяким требованиям, которые к нему предъявляются.
Допускаю, что документ возможно хорош для каких-то своих целей, но в таком виде некоторым ИТ компаниям он явно может оказать «медвежью услугу» и не простую, а многоаспектную.
Конечно же, кроме единственного советского «Оператора ЭВМ» в ИТ отрасли должны быть и какие-то другие специалисты, но есть большие опасения возникновения в компаниях состояния «перебора» от такого количества «мастей» менеджеров-коммерсантов.
Может в этом документе и всё изумительно правильно написано, просто «очень профессиональные» слова использованы и смысл написанного ускользает от обычного ИТ специалиста. Но, как же читателю понять это, если даже самого бестолкового словаря не предусмотрено?
Не знаю, как у вас, а у меня напрашивается вывод один:
Не тянет как-то этот документ на рождественский подарок ИТ сообществу. Не радостный он.
Искренне жалею уважаемых авторов, которые с подачи Федора Тимофеевича (автора макета стандарта) и Министерства
Никого не желаю обидеть, просто констатирую факт по уже утвержденному стандарту.
Тем не менее, очень хочется спросить самих авторов документа из компаний со звучными названиями:
- Действительно ли использовался "Системный подход" при разработке этого продукта, какой? Почему при таком прогрессивном подходе это осталось не задокументировано?
- Какие "… предприятия компьютерных и информационных технологий" были выбраны в качестве эталона для тщательного "… системного анализа" установленных у них технологических и деловых процессов, которые «вдруг» потребовали привлечения трудовых ресурсов именно такого рода? И почему они были избраны, как эталон?
- Почему в "1С" входной язык почти русский, а в стандарте применяется странно-неоднозначное заимствованное слово «менеджер» без каких либо разъяснений его значения для русскоязычного читателя?
Есть ли вообще возможность прояснить ситуацию с этой, вроде как по-определению руководящей(!) должностью, в случае «ассистент младшего менеджера» — кто такому в организационной иерархии будет подотчётен? Или предполагается, что эта должность вообще не административная, т.е. это просто недоАналитик с начальным(!) профессиональным образованием «заточенный» на торговлю и нанимаемый для перекладывания бумажек по модерновой безбумажной технологии?
И главный вопрос к авторам:
Какие авторитетные труды\материалы\издания\исследования легли в основу этого стандарта?
Ведь без ответов на подобные вопросы абсолютно невозможно определиться со степенью возможного доверия к этому «стандарту».
Вот, к примеру:
Вдруг мы не знаем, а уже таки появились секретные технологии, позволяющие «разрабатывать требования к качеству продукта» в рамках отдельно взятого «Трудового действия».
То есть делать это как-то отдельно от разработки других требований.
И это даже несмотря на то, что к продукту обычно предъявляется многоаспектный комплекс требований, в котором безусловно каждое значимое требование влияет на качество продукта.
Вдруг мы должны уже просто забыть про то, что качество продукта как раз и определяется его возможностями удовлетворить всяким требованиям, которые к нему предъявляются.
Допускаю, что документ возможно хорош для каких-то своих целей, но в таком виде некоторым ИТ компаниям он явно может оказать «медвежью услугу» и не простую, а многоаспектную.
Конечно же, кроме единственного советского «Оператора ЭВМ» в ИТ отрасли должны быть и какие-то другие специалисты, но есть большие опасения возникновения в компаниях состояния «перебора» от такого количества «мастей» менеджеров-коммерсантов.
Может в этом документе и всё изумительно правильно написано, просто «очень профессиональные» слова использованы и смысл написанного ускользает от обычного ИТ специалиста. Но, как же читателю понять это, если даже самого бестолкового словаря не предусмотрено?
Не знаю, как у вас, а у меня напрашивается вывод один:
Не тянет как-то этот документ на рождественский подарок ИТ сообществу. Не радостный он.
Какие авторитетные труды\материалы\издания\исследования легли в основу этого стандарта?
Поддерживаю вопрос предыдущего комментатора, расскажите где найти эти Ваши теории, которые так красиво написаны в необходимых знаниях в описании трудовых функций(например «Теория портфельного управления», «Теория процессного управления», «Теория компетенций»)?
Ссылки на авторов стандарта оставили, а на источники нет, почему?
Мне тоже понравилась Теория портфельного управления :-)
Эх, к Рождеству надо настоящее чудо просить!
Не интересно же спрашивать про то, что уже упомянуто в стандарте. Интереснее про то, чего ещё нет…
Спросите сразу про «Теорию управления рисками» :-)
Это даже более актуально для гильдии менеджеров, чем всё перечисленное. Потому, что это коротко связано с деньгами.
К стати, в прошлом веке в СССР, когда ещё несоблюдение стандартов каралось по закону, эту теорию не оставляли без внимания. Сам свидетель, когда после игр с привлечением «Теории вероятности» выход годного при массовом производстве повышался с 30% до 90%. Вот такое было управление риском брака.
Не интересно же спрашивать про то, что уже упомянуто в стандарте. Интереснее про то, чего ещё нет…
Спросите сразу про «Теорию управления рисками» :-)
Это даже более актуально для гильдии менеджеров, чем всё перечисленное. Потому, что это коротко связано с деньгами.
К стати, в прошлом веке в СССР, когда ещё несоблюдение стандартов каралось по закону, эту теорию не оставляли без внимания. Сам свидетель, когда после игр с привлечением «Теории вероятности» выход годного при массовом производстве повышался с 30% до 90%. Вот такое было управление риском брака.
Потому что вы первые, кто этим заинтересовался из нескольких тысяч просмотревших пост?
Вот тут я указал перечень источников: habrahabr.ru/post/246583/#comment_8197271
Вы правда думаете, что вопрос «где найти теорию портфельного управления» — это вопрос к тексту стандарта?
Вот тут я указал перечень источников: habrahabr.ru/post/246583/#comment_8197271
Вы правда думаете, что вопрос «где найти теорию портфельного управления» — это вопрос к тексту стандарта?
Вы правда думаете, что вопрос «где найти теорию портфельного управления» — это вопрос к тексту стандарта?
Ну а как иначе-то? Представьте заинтересованный читатель, увидев такое, набирает в поисковике название Теории, изучает и приобретает ценные знания в области… управления ценными бумагами.
Или я не понял, ваши Менеджеры имею такой широкий профиль, что хватает и для улыбки соответствующего размера — это ещё и спецы рынка ценных бумаг? Представляю себе такого Менеджера: «Босс, мой проект имеет плохую отдачу в этом квартале… давай сольём оборудование и эти деньги я лучше в ГКО вложу...»
Назвав, стандарт "… в вакууме" я не издевался, а высветил отсутствие базиса и внешних связей стандарта.
Почему создатели «стандарта» позволили себе отвергнуть опыт человечества, которое веками снабжала свои шедевры разделом «Список литературы»?
Это же прописные истины, которые обязательно надо знать всем, и особенно составителям стандартов.
Я вам по секрету скажу, что есть Закон:
"… Участники работ по стандартизации, а также национальные стандарты, предварительные национальные стандарты, общероссийские классификаторы технико-экономической и социальной информации, правила их разработки и применения, правила стандартизации, нормы и рекомендации в области стандартизации, своды правил образуют национальную систему стандартизации.
www.consultant.ru/popular/techreg/45_3.html#p377
© КонсультантПлюс, 1992-2014"
Или у вас есть ноу-хау, позволяющее строить Систему без связей?
Но, не беспокойтесь, юридически составители этого стандарта, вроде как, чисты — ваш «стандарт» не технический.
Он скорее гуманитарный :-)
Конкретно по портфельному управлению смотрите хотя бы стандарт PMI: www.pmpractice.ru/knowledgebase/normative/portfolio/management/
По теории компетенций хороша книга Спенсера: www.amazon.com/Competence-Work-Models-Superior-Performance/dp/047154809X
Ссылки по процессному управлению: en.wikipedia.org/wiki/Process_management#Further_reading
По теории компетенций хороша книга Спенсера: www.amazon.com/Competence-Work-Models-Superior-Performance/dp/047154809X
Ссылки по процессному управлению: en.wikipedia.org/wiki/Process_management#Further_reading
Отличный анализ!
«Действительно ли использовался «Системный подход» при разработке этого продукта, какой? Почему при таком прогрессивном подходе это осталось не задокументировано?»
А кто это утверждал, что используется системный подход? Подход к разработке профстандарта описывается в пояснительной записке, которая не публикуется в реестре профстандартов, а остаётся внутренним отчётным документом МинТруда. Макет профстандарта, как вы понимаете, не оставляет места для описания подхода.
А кто это утверждал, что используется системный подход? Подход к разработке профстандарта описывается в пояснительной записке, которая не публикуется в реестре профстандартов, а остаётся внутренним отчётным документом МинТруда. Макет профстандарта, как вы понимаете, не оставляет места для описания подхода.
А кстати, АП КИТ выложил и пояснительную записку тоже. Так что можете ознакомиться и с подходом (раздел 2 документа):
www.apkit.ru/committees/education/meetings/standarts.php
www.apkit.ru/committees/education/meetings/standarts.php
Давайте, добьемся вставки в стандарт одной ссылки… на эту переписку в Хабрахабр и вопрос будет решён —
Хабрахабр войдет в федеральную систему стандартизации :-)
Хабрахабр войдет в федеральную систему стандартизации :-)
вы не ответили на вопрос, откуда вы взяли пресуппозицию про системный подход
Разумеется я это взял на основе сакрального знания о потребности государства иметь систему стандартизации, разработка которой без использования системных подходов… дает наглядный результат.
И печаль моя от этого результата.
У Вас есть шанс немного развеять эту печаль, если сможете представить на суд публики всего две диаграммы:
Эталонную иерархическую организационную диаграмму, в которой присутствуют позиции всех(!) без исключения вариаций «стандартных» ИТ менеджеров.
Эталонный технологический IT процесс, в который вовлечены эти менеджеры
И строго, как на дуэле: «Выбор достойных графических языков для описания за вами...»
С такой «линейкой» можно будет тогда поговорить и о качестве стандарта, и о его применимости в быту…
И не хай, что сейчас висит этот стандарт в вакууме… промеряем, взвесим и оценим…
Не думаю, что это должно вызвать серьёзное напряжение… Ведь, во «внутренних отчётных документах МинТруда» наверняка есть какой-нибудь «Отчет об испытаниях стандарта». Так же-ж?
Однако, если применения этого стандарта «в быту» не предусматривается, то не надо тратить на это время…
И печаль моя от этого результата.
У Вас есть шанс немного развеять эту печаль, если сможете представить на суд публики всего две диаграммы:
Эталонную иерархическую организационную диаграмму, в которой присутствуют позиции всех(!) без исключения вариаций «стандартных» ИТ менеджеров.
Эталонный технологический IT процесс, в который вовлечены эти менеджеры
И строго, как на дуэле: «Выбор достойных графических языков для описания за вами...»
С такой «линейкой» можно будет тогда поговорить и о качестве стандарта, и о его применимости в быту…
И не хай, что сейчас висит этот стандарт в вакууме… промеряем, взвесим и оценим…
Не думаю, что это должно вызвать серьёзное напряжение… Ведь, во «внутренних отчётных документах МинТруда» наверняка есть какой-нибудь «Отчет об испытаниях стандарта». Так же-ж?
Однако, если применения этого стандарта «в быту» не предусматривается, то не надо тратить на это время…
Ну я тоже считаю, что законы должны разрабатываться с применением системного моделирования последствий, вероятностей, рисков, устройства окружающей экосистемы и т.д.
Но разрабатываются они в основном как-то совсем по-другому — в режиме «вот есть инициатива на уровне «если запретить A, то B сократится»».
Так чего же вы ожидаете от нишевых документов?
«Представить на суд публики» — что у вас за тон тут такой, типа допроса с пристрастием? Какая дуэль?
Я же писал выше, что взаимоувязанной картины профессий из этих стандартов нет.
Кроме того, ряд профессий применим в одном контексте, ряд — в другом. И единого целостного процесса просто может не быть. Потому что, например, роль менеджера продукта имеет смысл только в продуктовой разработке, а не в заказной и не во внутренней.
Максимум, на что можно опереться — это на серию стандартов по процессам системной инженерии, 15288, 29148 и т.д. Но поскольку управление продуктами лежит на пересечении предпринимательства, маркетинга, процессов разработки и процессов управления работами (проектами, программами), то в системной инженерии ничего про маркетинг и продукты нет.
Отчёта об испытаниях нет. Я даже специально оговаривал, что мы не успели потестировать стандарт ввиду жёстких временных ограничений контракта: www.uml2.ru/forum/index.php?topic=2091.msg36437#msg36437
Но разрабатываются они в основном как-то совсем по-другому — в режиме «вот есть инициатива на уровне «если запретить A, то B сократится»».
Так чего же вы ожидаете от нишевых документов?
«Представить на суд публики» — что у вас за тон тут такой, типа допроса с пристрастием? Какая дуэль?
Я же писал выше, что взаимоувязанной картины профессий из этих стандартов нет.
Кроме того, ряд профессий применим в одном контексте, ряд — в другом. И единого целостного процесса просто может не быть. Потому что, например, роль менеджера продукта имеет смысл только в продуктовой разработке, а не в заказной и не во внутренней.
Максимум, на что можно опереться — это на серию стандартов по процессам системной инженерии, 15288, 29148 и т.д. Но поскольку управление продуктами лежит на пересечении предпринимательства, маркетинга, процессов разработки и процессов управления работами (проектами, программами), то в системной инженерии ничего про маркетинг и продукты нет.
Отчёта об испытаниях нет. Я даже специально оговаривал, что мы не успели потестировать стандарт ввиду жёстких временных ограничений контракта: www.uml2.ru/forum/index.php?topic=2091.msg36437#msg36437
Какая дуэль?
Утром на рассвете… как обычно. :-)
Для подготовки схем целая ночь впереди — достаточно же :-)
взаимоувязанной картины профессий из этих стандартов нет.
И Вы ещё спрашиваете про мою тоску-печаль?
А у вас-то у самих — экспертов — разработчиков стандарта какое впечатление после такой работы?
Неужели в Вашей команде не нашлось ни одной значимой фигуры, которая объяснила бы министрам «какая хрень у них творится»?
«Мыши кололись плакали, но продолжали есть кактусы»?
мы не успели потестировать стандарт
Потестировать стандарты в каких-то приёмочных сценариях
«Ну, Вы, блин даёте!» — сказал генерал из особенностей разработки национальных стандартов.
Можно и дальше обсуждать QA процессы для разработки стандартов, ответственность руководителей за качество в рамках мультисерийного стандарта ISO 90XаXа…
Утром на рассвете… как обычно. :-)
Для подготовки схем целая ночь впереди — достаточно же :-)
взаимоувязанной картины профессий из этих стандартов нет.
И Вы ещё спрашиваете про мою тоску-печаль?
А у вас-то у самих — экспертов — разработчиков стандарта какое впечатление после такой работы?
Неужели в Вашей команде не нашлось ни одной значимой фигуры, которая объяснила бы министрам «какая хрень у них творится»?
«Мыши кололись плакали, но продолжали есть кактусы»?
мы не успели потестировать стандарт
Потестировать стандарты в каких-то приёмочных сценариях
«Ну, Вы, блин даёте!» — сказал генерал из особенностей разработки национальных стандартов.
Можно и дальше обсуждать QA процессы для разработки стандартов, ответственность руководителей за качество в рамках мультисерийного стандарта ISO 90XаXа…
«Почему в «1С» входной язык почти русский, а в стандарте применяется странно-неоднозначное заимствованное слово «менеджер» без каких либо разъяснений его значения для русскоязычного читателя?»
Стандарт называется так, как его назвал в заказе МинКомСвязи.
Слово менеджер уже прочно вошло в корпус русского языка. Характер «менеджерства» как раз и раскрываются последующими за ним словами.
Было в России две беды. И придумали мудрые люди правила безопасного сосуществования с обоими бедами в 3D пространстве.
Но, МинКомСвязи, осваивая пространство им. Вирта, накликал ещё беду. И теперь, если терпеливо исполнять правило 3Д, то с большой вероятностью мимо неторопливо проплывет… менеджер с какой-нибудь специализацией. И скажет нам мудрец восточный: «Я понимать, у Вас Манагер, как Иванов, многая такая фамилия».
Не могу утверждать точно, но похоже Министерства вовлекли грамотных и образованных специалистов в процесс, имеющий целый ряд системных ошибок. Я так полагаю потому, что в хорошем процессе вовлеченные эксперты имели бы, как минимум, несколько шансов указать на эти ошибки и исправить их (на вскидку таких точек для выявления в этом процессе должно было быть быть штук 5-6).
Да теперь это даже слишком модное словечко у нас. Но это и стало причиной потери его смысла в отличие от английскогоэквивалента аналога созвучного слова. Согласитесь, что семантика потеряна напрочь.
В случае применения такого слова при разработке какого-нибудь международного стандарта, спецификации или любого подобного документа QA специалист обязательно должен был бы оставить в системе отслеживания ошибок запись со словами «ambiguous term». И я вас уверяю, это было бы исправлено очень быстро.
Задумайтесь, мы заимствовали слово. Ну, типа взяли кредит по которому нам придется расплачиваться долгие годы, каждый раз объясняя: «Ну, у нас это не совсем менеджер в истинном понимании значения этого слова. У нас офис-менеджер это секретарша, менеджер у прилавка это продавец, а ассистент младшего менеджера это… ну, как бы вам объяснить получше… ».
Представьте себе только стоимость чернил, которые на это будет потрачено? Ведь много Менеджеров смогли бы безбедно прожить остаток жизни на такие деньги не пачкаясь в чернилах.
Но, МинКомСвязи, осваивая пространство им. Вирта, накликал ещё беду. И теперь, если терпеливо исполнять правило 3Д, то с большой вероятностью мимо неторопливо проплывет… менеджер с какой-нибудь специализацией. И скажет нам мудрец восточный: «Я понимать, у Вас Манагер, как Иванов, многая такая фамилия».
Не могу утверждать точно, но похоже Министерства вовлекли грамотных и образованных специалистов в процесс, имеющий целый ряд системных ошибок. Я так полагаю потому, что в хорошем процессе вовлеченные эксперты имели бы, как минимум, несколько шансов указать на эти ошибки и исправить их (на вскидку таких точек для выявления в этом процессе должно было быть быть штук 5-6).
Слово менеджер уже прочно вошло в корпус русского языка.
Да теперь это даже слишком модное словечко у нас. Но это и стало причиной потери его смысла в отличие от английского
В случае применения такого слова при разработке какого-нибудь международного стандарта, спецификации или любого подобного документа QA специалист обязательно должен был бы оставить в системе отслеживания ошибок запись со словами «ambiguous term». И я вас уверяю, это было бы исправлено очень быстро.
Задумайтесь, мы заимствовали слово. Ну, типа взяли кредит по которому нам придется расплачиваться долгие годы, каждый раз объясняя: «Ну, у нас это не совсем менеджер в истинном понимании значения этого слова. У нас офис-менеджер это секретарша, менеджер у прилавка это продавец, а ассистент младшего менеджера это… ну, как бы вам объяснить получше… ».
Представьте себе только стоимость чернил, которые на это будет потрачено? Ведь много Менеджеров смогли бы безбедно прожить остаток жизни на такие деньги не пачкаясь в чернилах.
«Какие авторитетные труды\материалы\издания\исследования легли в основу этого стандарта?»
В слайдах презентации профстандарта на круглом стол год назад есть перечень: www.apkit.ru/committees/education/projects/Product%20manager.php
Давайте я вам процитирую источники:
Материалы профессиональных ассоциаций
• PDMA: Product Development and Management Association
• AIPMM: Association of International Product Marketing Managers
• ISPMA: International Software Product Management Asscociation
• SVPMA: Silicon Valley Product Management Association
Материалы консалтинговых компаний
• Pragmatic Marketing, 280 Group, BlackBlot, Sequential Learning
Материалы отраслевых движений
• Lean Startup, Product Camps, Product Tanks
Вдруг мы не знаем, а уже таки появились секретные технологии, позволяющие «разрабатывать требования к качеству продукта» в рамках отдельно взятого «Трудового действия».
То есть делать это как-то отдельно от разработки других требований.
И это даже несмотря на то, что к продукту обычно предъявляется многоаспектный комплекс требований, в котором безусловно каждое значимое требование влияет на качество продукта.
Вдруг мы должны уже просто забыть про то, что качество продукта как раз и определяется его возможностями удовлетворить всяким требованиям, которые к нему предъявляются.
Как специалист по требованиям, я много лет подряд наблюдаю, как множество авторов документов требований, ТЗ, БЗ и прочих ХЗ старательно описывают функции продукта/системы/объекта поставки, но в большей или меньшей степени игнорируют формулирование требований к его качеству. Если вы давно не открывали ISO 9126 / ISO 25010, то я напомню, что функциональность — это только один из множества компонентов качества систем/софта.
И я могу утверждать как профессионал в этой теме, что эти требования могут разрабатываться независимо. Другое дело, что при их сведении нужно делать анализ их совместимости, а подрядчику/исполнителю — обязательно восприминимать их в комплексе.
И да, требования к качеству продукту могут быть разработаны за одно трудовое действие. Например, при использовании шаблонов (типовых профилей качества) рабочая группа может разработать требования к заказному или продуктовому ПО малого/среднего масштаба за одну рабочую сессию (1-2 часа), что можно увидеть на моих тренингах по разработке ТЗ, например.
Десятилетиями на сотнях примерах убеждаюсь в справедливости фразы, которую говорил выдающийся человек — профессор Петр Петрович Гель своим студентам на первой же лекции по конструированию:
«К сожалению, научить разрабатывать нельзя! Это либо дано, либо...».
Либо жизнь заставляет Вас готовить специалистов по разработке требований из того, что есть.
Попытка использовать шаблоны, которые заранее разработаны «людьми со способностями» это хорошая попытка.
Но, на примере Макета для вашего стандарта и Методических рекомендаций к нему, мы видим совсем иную ситуацию.
Надеюсь ваши шаблоны содержат раздел «Область применения» или там так же, как со «Списком литературы» в стандарте?
И ваша первая тема на тренинге это «Шаблоны и правила выбора подходящего», а вторая тема «Что делать, если подходящего шаблона нет?»
Эх, жаль Peter Coad «забил» на свой бизнес — у него и его команды изумительно получалось жонглировать всякими шаблонами. Мир много потерял от этого. Надеюсь, по роду своей деятельности Вы отслеживаете все современные достижения в этой области… Судя по Вашим словам выше, свято место пока пусто. Или нет?
К стати, Вы своими словами только что подтвердили обязательность наличия в стандартах, учебных пособиях и т.д. раздела «Определения».
Попробуйте дать определение для термина «Качество продукта» (или найдите готовое в стандартах — только не в учебниках и популярных книжках — я там такой бред встречал — ужас, наши стандарты, к стати, тоже очень «хромают» в части терминологии) для лучшего собственного понимания, сравните несколько различных определений для приближения к «математическому ожиданию и уменьшения дисперсии». Далее определите коэффициенты корреляции для каждого требования при вычислении целевой функции качества.
При этом ужаснитесь: «Ой, все(!) > 0. Что же делать!?».
Я доходчиво объяснил?
Все те определения, которые известны мне, а также мой личный скромный опыт, позволяют заявить, что ваша методика, обособляющая требования к качеству, ошибочна. Причем, цена этой ошибки будет очень-очень высока — Вы её распространяете, обучая людей и разрабатывая стандарты.
Но, это так, замечание в сторону. Я буду рад, если это замечание принесет пользу. Но, мне совершенно не хочется разворачивать на поле Хабрахабр «Битву Водогреев» по данному вопросу — не тот формат. К тому же, моё имя уже по любому определяет победителя :-)
«К сожалению, научить разрабатывать нельзя! Это либо дано, либо...».
Либо жизнь заставляет Вас готовить специалистов по разработке требований из того, что есть.
Попытка использовать шаблоны, которые заранее разработаны «людьми со способностями» это хорошая попытка.
Но, на примере Макета для вашего стандарта и Методических рекомендаций к нему, мы видим совсем иную ситуацию.
Надеюсь ваши шаблоны содержат раздел «Область применения» или там так же, как со «Списком литературы» в стандарте?
И ваша первая тема на тренинге это «Шаблоны и правила выбора подходящего», а вторая тема «Что делать, если подходящего шаблона нет?»
Эх, жаль Peter Coad «забил» на свой бизнес — у него и его команды изумительно получалось жонглировать всякими шаблонами. Мир много потерял от этого. Надеюсь, по роду своей деятельности Вы отслеживаете все современные достижения в этой области… Судя по Вашим словам выше, свято место пока пусто. Или нет?
К стати, Вы своими словами только что подтвердили обязательность наличия в стандартах, учебных пособиях и т.д. раздела «Определения».
Попробуйте дать определение для термина «Качество продукта» (или найдите готовое в стандартах — только не в учебниках и популярных книжках — я там такой бред встречал — ужас, наши стандарты, к стати, тоже очень «хромают» в части терминологии) для лучшего собственного понимания, сравните несколько различных определений для приближения к «математическому ожиданию и уменьшения дисперсии». Далее определите коэффициенты корреляции для каждого требования при вычислении целевой функции качества.
При этом ужаснитесь: «Ой, все(!) > 0. Что же делать!?».
Я доходчиво объяснил?
Все те определения, которые известны мне, а также мой личный скромный опыт, позволяют заявить, что ваша методика, обособляющая требования к качеству, ошибочна. Причем, цена этой ошибки будет очень-очень высока — Вы её распространяете, обучая людей и разрабатывая стандарты.
Но, это так, замечание в сторону. Я буду рад, если это замечание принесет пользу. Но, мне совершенно не хочется разворачивать на поле Хабрахабр «Битву Водогреев» по данному вопросу — не тот формат. К тому же, моё имя уже по любому определяет победителя :-)
Виктор, поделитесь опытом, который показывает, почему вредно писать в одном требовании к системе «Система должна позволять пользователю создавать новые заказы», а в другом — «Время создания заказа для обученного пользователя не должно превышать 3 минут в 80% случаев», например?
Зачем Вам пользоваться опытом неизвестно Виктора.
Возьмите лучше авторитетный источник, ну, хотя бы какой-нибудь IEEE Recommended Practice for Software Requirements Specifications. Он старый и добрый — он поможет. Примените его положения к своим требованиям и поймите почему оба(!) ваших варианта не «good».
А если интересно моё мнение, то у меня не хватило пальцев на руках, считая «недочеты» к этим двум требованиям.
Уточню, у меня на руках 10 пальцев.
Возьмите лучше авторитетный источник, ну, хотя бы какой-нибудь IEEE Recommended Practice for Software Requirements Specifications. Он старый и добрый — он поможет. Примените его положения к своим требованиям и поймите почему оба(!) ваших варианта не «good».
А если интересно моё мнение, то у меня не хватило пальцев на руках, считая «недочеты» к этим двум требованиям.
Уточню, у меня на руках 10 пальцев.
Какие именно положения IEEE SRS 830-1998 неприменимы к этим требованиям? Давайте конкретно, если уж взялись.
Нет уж, увольте. Вы сами назвались профессионалом в этом. Так что, сами, сами, сами, пожалуйста.
«Главная задача высшей школы это научить студентов (от лат. studens — усердно работающий, занимающийся, интересующийся) к самостоятельному обучению и обретению новых навыков»
из материалов XVI съезда КПСС.
«Главная задача высшей школы это научить студентов (от лат. studens — усердно работающий, занимающийся, интересующийся) к самостоятельному обучению и обретению новых навыков»
из материалов XVI съезда КПСС.
Увольняю. Признаю ваши нападки необоснованными и беспочвенными ввиду отказа от аргументации.
Увольнение принимаю. Вы не первый, кто говорит мне, что я своими словами заставляю работать.
У вас сейчас есть всё, что бы самому получить ответы на свои вопросы. Уверяю, это не сложно. Надо только абстрагироваться от имеющихся у вас в голове догм и шаблонов (не важно даже какие они!). Открываете главу «4. Considerations for producing a good SRS» и формально\пунктуально примеряете эти положения на свои утверждения\требования к Системе.
У вас сейчас есть всё, что бы самому получить ответы на свои вопросы. Уверяю, это не сложно. Надо только абстрагироваться от имеющихся у вас в голове догм и шаблонов (не важно даже какие они!). Открываете главу «4. Considerations for producing a good SRS» и формально\пунктуально примеряете эти положения на свои утверждения\требования к Системе.
Я, кстати, только ЗА определения в профстандартах, их там действительно не хватает. Надеюсь, в следующих версиях макетов это исправят.
На уровне пакета стандартов есть проблемы более фундаментальные — например, стандарты разных ИТ-профессий не согласованы между собой ни по терминологии, ни по устройству, ни по названиям функций/процессов/результатов.
Т.е. каждый стандарт представляет собой взгляд одной профессиональной группы, без интеграции его в полную картину.
На уровне пакета стандартов есть проблемы более фундаментальные — например, стандарты разных ИТ-профессий не согласованы между собой ни по терминологии, ни по устройству, ни по названиям функций/процессов/результатов.
Т.е. каждый стандарт представляет собой взгляд одной профессиональной группы, без интеграции его в полную картину.
«Не тянет как-то этот документ на рождественский подарок ИТ сообществу. Не радостный он.»
Мы и не собирались делать рождественский подарок. Мы разработали стандарт ещё в октябре 2013-го года, презентовали сообществу в форме вебинара и выступления на профильном отраслевом мероприятии.
То, что он получил гриф министра только в ноябре 2014, а мы соответственно узнали об этом только сейчас — следствие большого объёма работы у МинТруда (800 стандартов, если вы помните) и бюрократичности процедур.
У меня встречный вопрос к вам — а вы изучали другие ИТ-профстандарты из пакета, что заказал МинСвязи? Какой-то из них вас порадовал?
А то я пока не понимаю, как отнестись к тому, что вас шарики не радуют — может это свойство макета, в целом стандартов или конкретно этого?
А то я пока не понимаю, как отнестись к тому, что вас шарики не радуют — может это свойство макета, в целом стандартов или конкретно этого?
Поскольку автор поста в течение 2-х дней не ответил на моё сообщение в личку, пишу здесь:
Рабочая группа не Школы, а просто рабочая группа по созданию профстандарта.
Рабочая группа не Школы, а просто рабочая группа по созданию профстандарта.
Скажите пожалуйста, как стандарт будет применяться на практике?
Раскладка по более узким позициям может быть полезной для тех, кто хочет стать продактом. Но на практике, для компаний, конечно, важны практические результаты, а не теоретические познания продуктового менеджера.
Раскладка по более узким позициям может быть полезной для тех, кто хочет стать продактом. Но на практике, для компаний, конечно, важны практические результаты, а не теоретические познания продуктового менеджера.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Утверждён профстандарт менеджера ИТ-продуктов