Все идет от требований. Вся система разбита на подсистемы, на каждую подсистему назначен ответственный аналитик. В зависимости от того к какой подсистеме относится входящее требование, ответственный аналитик берет на себя руководство реализацией требования и отвечает за его реализацию вплоть до сдачи заказчику. Аналитик в числе прочего отвечает за своевременное назначение задач на разработчика и контроль своевременности выполнения. В случае назначения нескольких задач на разработчика он сам определяет какую задачу он будет делать сегодня. Последовательность выполнения выбирает сам исполнитель. Однако, на проекте согласованы наиболее общие правила определения приоритета задач. Каждый сотрудник знает что инциденты надо решать в первую очередь, но при наличии других задач нельзя тратить на них более 50% рабочего времени (если не было других указаний). Задача которая выполняется в интересах нескольких требований имеет приоритет над задачей в интересах меньшего числа требований. Кроме того, сделан еще один дашборд который позволяет осуществлять балансировку задач сотрудника в зависимости от требуемых сроков, изменения приоритетов задач и привлечения разработчиков для выполнения задач в интересах разных аналитиков/проектов (планирую подробно описать этот дашборд в одной из следующих статей - честно говоря хочется попробовать сделать плагин для JIRA, а потом писать статью). С помощью этого дашборда так же осуществляется контроль того, чтобы сотрудник не был загружен задачами более чем на 80%. В случае возникновения конфликтов - в расстановку приоритетов включается РП.
Как правило, в кошельке заказчика ограниченный бюджет, а в голове - желание решить все проблемы за эти деньги. Однако, IMHO, если исполнитель покажет заказчику, что его желания могут быть реализованы путем выполнения определенного перечня работ, каждая из которых оценивается в нормо-часах специалиста, у заказчика появляется возможность выбора - какие работы он может выполнить за свои деньги, а какие оставить на потом. Это основание для начала нормального диалога. Когда Вы приходите к автомобильному дилеру с желанием отремонтировать свой автомобиль и он формирует перечень работ, общую цену и планируемые сроки, если у Вас не хватает денег или времени, Вы же не оспариваете стоимость отдельных работ - вы выбираете из списка наиболее приоритетные или уходите в другой сервис. Другое дело, если исполнитель любыми путями хочет получить контракт. Это распространенная ситуация - когда контракты заключают одни, а отвечают за их реализацию другие. Вот тогда мы сталкиваемся с ситуацией "впихнуть невпихуемое". И именно тогда нормо-часы превращаются в профанацию. Конечно, ключевой момент здесь в корректности оценки отдельных работ. Для снижения неопределенности при оценке трудоемкости я стараюсь конечную стоимость согласовывать с заказчиком после формирования проектных решений (подробно описал как их формируют на моих проектах здесь) и при создании WBS, по необходимости, использую калькуляторы оценки трудоемкости задач, которые в свою очередь являются площадкой для диалога между РП/аналитиком планирующим задачи и непосредственным исполнителем.
Конечно, я хотел бы чтобы мои сотрудники стремились к совершенству. Однако с моей точки зрения - это стремление должно быть подкреплено результатами, которые можно выразить количественно. Попробую пояснить на примере. С одной стороны, можно охарактеризовать школьника, что он очень талантлив, скажем, в математике, долго ходил на факультатив и несколько лет занимался с лучшими учителями. Но, с другой - на мой взгляд, гораздо представительней будет, если сказать, что он, например, самостоятельно решил XX задач из конкретного раздела конкретного учебника, занял Х в олимпиаде X уровня и т.п. Да действительно - все сотрудники разные. Однако, на мой взгляд, квалификация так или иначе всегда проявляется количественно. Один лучше подтягивается, другой быстрее бегает. То и другое можно измерить. Как сложить эти показатели - это отдельная тема для разговора. Как вариант. В отношении уникальности: на своих проектах я стремлюсь к снижению уникальности решений через унификацию и нормирование работ аналитика. Об этом я подробно рассказывал в одной из своих предыдущих статей. Обратите внимание на калькулятор для оценки трудоемкости этих работ при планировании. При этом унификация - это не ограничение для творчества. Это инструмент оценки и задания уровня. Квалификационные сетки в спорте не отменяют рекордов. Если на проекте рождается что-то эксклюзивное - это повод добавить этот эксклюзив в резюме отдельной строкой. В шаблонах резюме нельзя зафиксировать требование на озарения и инсайты, но это не отменяет их на проекте.
Про замечание - рекомендации о разделении статей на более мелкие части слышу не в первый раз, но продолжаю упорствовать в своих заблуждениях. Для меня Хабр тем и интересен, что позволяет выражать мысли так как хочется, а не так как диктуют правила публикации научных статей или нормативно-технической документации. Сепарация философской и технической части разорвала бы причинно-следственные связи. Меня не пугает, если кто-то не сможет дочитать до конца. Я никого не стремлюсь "обращать" в свою веру. Эти статьи я пишу больше для себя и для тех кому этой статьи мало. Пишу, чтобы разложить по полочкам свой опыт и обсудить с теми кто способен понять и применять то, о чем я пишу. Технический регламент на пректе я предлагаю писать своим аналитикам на основе моих статей. Такой вот "реинженеринг".
Ответ на 1 вопрос: Я ленив - поэтому стремлюсь одним выстрелом убить нескольких "зайцев". Статья написана и для руководителя проекта, и для соискателя, и для действующего сотрудника, и для директора руководителя. Это правила, по которым обеспечивается на проекте взаимодействие руководства и сотрудника-аналитика. Это основа для индивидуального учебного плана развития. Это договоренности с директором об условиях повышения зарплаты аналитика. Это квалификационная сетка для определения уровня сложности задач в JIRA (для каждой задачи у нас на проекте фиксируется уровень квалификации, необходимый для ее решения, уровни квалификации соответствуют должностной сетке, однако уровень квалификации задачи не обязательно должен соответствовать должности исполнителя). Это фильтр предварительной очистки для кандидатов на должность (некоторые, ознакомившись со статьей, отказывались от собеседования; некоторые наоборот переоценивали свои силы и стремились попасть на вакансию).
Ответ на 2 вопрос:
Судя по тексту вопроса, понятия "шедевр" и "качественный результат работы" для Вас тождественны, а вот для меня - нет. В промышленной разработке, понятие "качество" для меня означает соответствие требованиям заказчика. И не больше. Для того чтобы обеспечить качество выполнения задач, у нас есть подзадачи на рецензирование проектных решений аналитика со стороны РП и программистов. Кроме того, эти проектные решения должны быть внедрены в промышленную эксплуатацию. Конечная количественная оценка осуществляется именно по фактам сдачи результата работ заказчику. Более подробно о планировании и оценке результатов работ сотрудников на моих проектах предполагаю написать в следующей статье. Спасибо за оценку статьи - мотивирует на дальнейшее творчество.
Повторюсь - это не список обязанностей - это список ожидаемых компетенций, хотя, конечно, в контексте статьи, эти понятия близки друг другу. Обратите внимание, что первая компетенция системного аналитика указанная в этой статье - Управление требованиями. Учитывая важность этой компетенции - по данному вопросу написана отдельная статья (переходите по ссылке). Кроме того, ранее написана отдельная статья по формированию и нюансам согласования с представителями заказчика проектных решений, контроль исполнения которых так же входит в компетенции аналитика. Как результат работы аналитика выступает количество внедренных в промышленную эксплуатацию проектных решений. Надеюсь, в этих двух статьях Вы найдете ответы на свои вопросы. Так же, хотел бы предостеречь от обобщений. В статье неоднократно отмечено, что предложенный подход не может быть рассмотрен как общие правила на всех проектах Ланит и является личной позицией автора. Решение, применять или нет такой подход на своих проектах - остается за Вами.
Смущает широкое использование поправочных коэффициентов. Рекомендую обратить внимание на методику PERT. Пару калькуляторов (для оценки работ аналитиков и программистов) работающих по этой методике можно посмотреть здесь.
Я не настаиваю на своей точке зрения. Если у Вас получается добиваться успеха в проекте без того, чтобы аналитики разбирались в структуре БД - да пребудет с Вами сила. Иногда такое возможно. Например, при использовании Drupal или ОПОРА.УФОС, как платформы для создания ПО, значение понимания структуры БД уходит на второй план. Однако, точно не будет лишним. К сожалению, несмотря на атакующее отрицание предложенных подходов, ни один из критиков не предложил собственных критериев измерения эффективности аналитической работы. Может поделитесь, в каких "попугаях" измеряются у вас результаты работы аналитика?
Спасибо за наводку. Хорошо дополняет мысль высказанную в начале статьи - обязательно дам почитать своим сотрудникам. Сразу вспомнилась фраза Генри Форда: "Если у Вас появился незаменимый сотрудник, лучшее что Вы можете сделать - это уволить его."
Альбом выходных документов - документ содержащий описание отчетов выводимых на печать (на бумагу), а так же правила построения таких отчетов. Иногда нормативные акты требуют построения отчетов, которые просто нельзя построить на основе имеющихся исходных данных. Поэтому, несмотря на кажущуюся "понятность" отчетов, стоит фиксировать алгоритм представления данных на бумаге.
Пример описания систем классификации и кодирования можете посмотреть здесь.
Ретро-данные - данные которые попали в БД на предыдущих этапах ее существования или данные заказчика которые надо загрузить в БД при вводе системы в эксплуатацию. Зачастую выясняются, что эти данные не соответствуют принятым в БД ограничениям, но загружать/запускать систему надо срочно, ограничения БД снимаются. О необходимости принятия решения по исправлению этих данных (или хотя бы описанию этих противоречий) вскоре забывают. И через некоторое время "внезапно" начинается головная боль, источник которой удается обнаружить далеко не сразу...
Утверждение, конечно, понятно - Путь самурая доступен не всем. Непонятна категоричность, с которой он отвергается. Когда Вы говорите об увольнении - вы говорите на самом деле о страхе увольнения. А я говорю о искренности и объективности оценки своих компетенций. Это другое.
Конечно, перечень материалов избыточен, чтобы каждый мог найти свой путь роста.
IMHO - IDEF0 - от общего к частному. Не считаю, что БД - это не уровень аналитика. Напротив, считаю, что БД - это модель реального мира. И спроектировать такую модель, не представляя как этот мир устроен, это как написать картину с закрытыми глазами. Однако, без понимания того, что будешь использовать в работе - краски или уголь - тоже написать картину не получится.
Почему несправедливой? ВУЗы придумали для формирования массовых специальностей. А в приведенном примере речь шла об уникальной профессии. В определенных отраслях цеховая система обучения не умерла. Иногда выучить учебники недостаточно. Эта тема хорошо раскрывается в диалогах Учителя (Николо Амати) и Ученика (Антонио Страдивари) в фильме "Визит к Минотавру". Рекомендую.
На проектах, которыми я руковожу, нет господ. Как и нет холопов. Это принципиальный момент в организации работы. Вы пытаетесь анализировать приведенную матрицу, как должностную инструкцию. Это не должностная инструкция - это примерный перечень целей, ориентиров к которым, с моей точки зрения может стремиться аналитик на заказном программном проекте. При этом цели выставлены немного выше, чем требуется. С моей точки зрения, ведущий аналитик проекта должен являться ключевым интегрирующим звеном в проектировании архитектуры ПО, поскольку он является техническим представителем заказчика на проекте. Однако, к проектированию архитектуры должны привлекаться все технические специалисты по мере необходимости. Повторюсь, что способность разрабатывать структуру БД для аналитика считаю одной из ключевых компетенций. При этом считаю, в большинстве случаев, нецелесообразным формирование промежуточных моделей (ER и логической), поскольку можно сразу создавать физическую. На моих проектах аналитик создает структуру БД, после чего она проходит рецензирование со стороны программистов - по их замечаниям формируется вариант, который пойдет в эксплуатацию.
Все, что Вы перечислили - это проблемы заказчика и условия программных проектов. Зачастую, это все так. Как решаю эти проблемы на своих проектах, я писал в предыдущих статьях. Однако, эта статья о другом. Здесь я говорю о путях личного совершенствования сотрудника (в рамках одной из ролей проектной группы). Другими словами - Вы говорите о боли пациентов, симптомах болезней, об условиях, с которыми часто встречаешься в больницах. А я - о квалификации определенной категории врачей, которые входят в состав операционной бригады и , что важно для меня, о их мотивах в профессии.
По моему опыту, к сожалению, в комментариях на Хабре слово "словоблудие" очень часто является заменой словосочетанию "я ничего не понял". Если у Вас есть на затронутую тему собственная позиция - Вы можете отразить ее в своих статьях. Удачи.
В статье нет рекомендаций применять матрицу Д. Сиджина на собеседованиях. Для меня она послужила неплохим путеводителем на пути моего личного профессионального роста, высветив темные пятна на которые я не обращал внимания. С моей точки зрения, любая матрица компетенций - всегда только инструмент. И как для любого инструмента, результат его применения очень сильно зависит от целей того, как Вы собираетесь этот инструмент использовать. В частности от того, где Вы собираетесь поставить запятую в предложении: "Топить не стоит помогать".
Бесплатные сертификаты можно получить, разве только, на ресурсе intuit.ru, пройдя тестирование по соответствующим курсам. Я бы предостерег Вас от получения ВСЕХ перечисленных сертификатов. Как бы с водой не выплеснуть ребенка. В случае начинающего аналитика для меня интересны только сертификаты базового уровня по SQL и по BMP (их стоимость минимальна по сравнению с другими сертификатами для аналитика). Именно получение этих сертификатов я рекомендую своим начинающим аналитикам. Все остальные - по желанию и по необходимости.
В 1986 году наверное в каждом военном училище уже был свой собственный вычислительный центр. Выглядел он примерно так, как на добавленной фотографии. Любой преподаватель или курсант мог воспользоваться мощностями этого центра. Герой статьи, будучи курсантом подготовил несколько программ для расчета электронных схем именно на этих машинах. Программировали на Fortran или PL, используя перфокарты или прямо с терминала (ОС Примус). Так что слухи о дороговизне и дефицитности машинного времени сильно преувеличены. Кстати, в некоторых ввузах примерно в это же время стали появляться первые персональные компьютеры серии ЕС-184* (те, что на базе аналога знаменитого процессора i8086).
1 случай — требования на развитие ПО — например утвержденное ТЗ. Они сразу уходят на аналитика. «Атомизация» — это первичная регистрация в JIRA каждого требования (если хотите абзаца) ТЗ отдельно.
2 случай — это работа по ошибкам. Группа сопровождения — это первая линия — которая берет на себя задачу регистрации, разбиения (атомизации), сбора сопроводительных материалов и других подготовительных действий до передачи аналитику. При невысоком количестве ошибок от пользователей эти функции может выполнять аналитик.
Как то так.
Однако, замечу, что предложенные процессы не есть истина в последней инстанции. То что работает у нас — не факт, что будет эффективно в ваших условиях.
Все идет от требований. Вся система разбита на подсистемы, на каждую подсистему назначен ответственный аналитик. В зависимости от того к какой подсистеме относится входящее требование, ответственный аналитик берет на себя руководство реализацией требования и отвечает за его реализацию вплоть до сдачи заказчику. Аналитик в числе прочего отвечает за своевременное назначение задач на разработчика и контроль своевременности выполнения. В случае назначения нескольких задач на разработчика он сам определяет какую задачу он будет делать сегодня. Последовательность выполнения выбирает сам исполнитель. Однако, на проекте согласованы наиболее общие правила определения приоритета задач. Каждый сотрудник знает что инциденты надо решать в первую очередь, но при наличии других задач нельзя тратить на них более 50% рабочего времени (если не было других указаний). Задача которая выполняется в интересах нескольких требований имеет приоритет над задачей в интересах меньшего числа требований. Кроме того, сделан еще один дашборд который позволяет осуществлять балансировку задач сотрудника в зависимости от требуемых сроков, изменения приоритетов задач и привлечения разработчиков для выполнения задач в интересах разных аналитиков/проектов (планирую подробно описать этот дашборд в одной из следующих статей - честно говоря хочется попробовать сделать плагин для JIRA, а потом писать статью). С помощью этого дашборда так же осуществляется контроль того, чтобы сотрудник не был загружен задачами более чем на 80%. В случае возникновения конфликтов - в расстановку приоритетов включается РП.
Все стадии подробно описаны в статье https://habr.com/ru/company/lanit/blog/486754/ . Стадии анализа подробно детализированы в статье https://habr.com/ru/company/lanit/blog/515452/
Кодревью формируется как подзадача к задаче типа разработка и выполняется после того как аналитик примет доработанный функционал (перед заливкой ветки разработки в develop - https://habr.com/ru/company/lanit/blog/515452/ ). Если нужны дополнительные уточнения - пишите - попробую ответить.
Как правило, в кошельке заказчика ограниченный бюджет, а в голове - желание решить все проблемы за эти деньги. Однако, IMHO, если исполнитель покажет заказчику, что его желания могут быть реализованы путем выполнения определенного перечня работ, каждая из которых оценивается в нормо-часах специалиста, у заказчика появляется возможность выбора - какие работы он может выполнить за свои деньги, а какие оставить на потом. Это основание для начала нормального диалога.
Когда Вы приходите к автомобильному дилеру с желанием отремонтировать свой автомобиль и он формирует перечень работ, общую цену и планируемые сроки, если у Вас не хватает денег или времени, Вы же не оспариваете стоимость отдельных работ - вы выбираете из списка наиболее приоритетные или уходите в другой сервис.
Другое дело, если исполнитель любыми путями хочет получить контракт. Это распространенная ситуация - когда контракты заключают одни, а отвечают за их реализацию другие. Вот тогда мы сталкиваемся с ситуацией "впихнуть невпихуемое". И именно тогда нормо-часы превращаются в профанацию.
Конечно, ключевой момент здесь в корректности оценки отдельных работ. Для снижения неопределенности при оценке трудоемкости я стараюсь конечную стоимость согласовывать с заказчиком после формирования проектных решений (подробно описал как их формируют на моих проектах здесь) и при создании WBS, по необходимости, использую калькуляторы оценки трудоемкости задач, которые в свою очередь являются площадкой для диалога между РП/аналитиком планирующим задачи и непосредственным исполнителем.
Конечно, я хотел бы чтобы мои сотрудники стремились к совершенству. Однако с моей точки зрения - это стремление должно быть подкреплено результатами, которые можно выразить количественно. Попробую пояснить на примере. С одной стороны, можно охарактеризовать школьника, что он очень талантлив, скажем, в математике, долго ходил на факультатив и несколько лет занимался с лучшими учителями. Но, с другой - на мой взгляд, гораздо представительней будет, если сказать, что он, например, самостоятельно решил XX задач из конкретного раздела конкретного учебника, занял Х в олимпиаде X уровня и т.п. Да действительно - все сотрудники разные. Однако, на мой взгляд, квалификация так или иначе всегда проявляется количественно. Один лучше подтягивается, другой быстрее бегает. То и другое можно измерить. Как сложить эти показатели - это отдельная тема для разговора. Как вариант.
В отношении уникальности: на своих проектах я стремлюсь к снижению уникальности решений через унификацию и нормирование работ аналитика. Об этом я подробно рассказывал в одной из своих предыдущих статей. Обратите внимание на калькулятор для оценки трудоемкости этих работ при планировании. При этом унификация - это не ограничение для творчества. Это инструмент оценки и задания уровня. Квалификационные сетки в спорте не отменяют рекордов. Если на проекте рождается что-то эксклюзивное - это повод добавить этот эксклюзив в резюме отдельной строкой. В шаблонах резюме нельзя зафиксировать требование на озарения и инсайты, но это не отменяет их на проекте.
Про замечание - рекомендации о разделении статей на более мелкие части слышу не в первый раз, но продолжаю упорствовать в своих заблуждениях. Для меня Хабр тем и интересен, что позволяет выражать мысли так как хочется, а не так как диктуют правила публикации научных статей или нормативно-технической документации. Сепарация философской и технической части разорвала бы причинно-следственные связи. Меня не пугает, если кто-то не сможет дочитать до конца. Я никого не стремлюсь "обращать" в свою веру. Эти статьи я пишу больше для себя и для тех кому этой статьи мало. Пишу, чтобы разложить по полочкам свой опыт и обсудить с теми кто способен понять и применять то, о чем я пишу. Технический регламент на пректе я предлагаю писать своим аналитикам на основе моих статей. Такой вот "реинженеринг".
Ответ на 1 вопрос:
Я ленив - поэтому стремлюсь одним выстрелом убить нескольких "зайцев". Статья написана и для руководителя проекта, и для соискателя, и для действующего сотрудника, и для директора руководителя. Это правила, по которым обеспечивается на проекте взаимодействие руководства и сотрудника-аналитика. Это основа для индивидуального учебного плана развития. Это договоренности с директором об условиях повышения зарплаты аналитика. Это квалификационная сетка для определения уровня сложности задач в JIRA (для каждой задачи у нас на проекте фиксируется уровень квалификации, необходимый для ее решения, уровни квалификации соответствуют должностной сетке, однако уровень квалификации задачи не обязательно должен соответствовать должности исполнителя). Это фильтр предварительной очистки для кандидатов на должность (некоторые, ознакомившись со статьей, отказывались от собеседования; некоторые наоборот переоценивали свои силы и стремились попасть на вакансию).
Ответ на 2 вопрос:
Судя по тексту вопроса, понятия "шедевр" и "качественный результат работы" для Вас тождественны, а вот для меня - нет. В промышленной разработке, понятие "качество" для меня означает соответствие требованиям заказчика. И не больше. Для того чтобы обеспечить качество выполнения задач, у нас есть подзадачи на рецензирование проектных решений аналитика со стороны РП и программистов. Кроме того, эти проектные решения должны быть внедрены в промышленную эксплуатацию. Конечная количественная оценка осуществляется именно по фактам сдачи результата работ заказчику. Более подробно о планировании и оценке результатов работ сотрудников на моих проектах предполагаю написать в следующей статье.
Спасибо за оценку статьи - мотивирует на дальнейшее творчество.
Повторюсь - это не список обязанностей - это список ожидаемых компетенций, хотя, конечно, в контексте статьи, эти понятия близки друг другу.
Обратите внимание, что первая компетенция системного аналитика указанная в этой статье - Управление требованиями. Учитывая важность этой компетенции - по данному вопросу написана отдельная статья (переходите по ссылке). Кроме того, ранее написана отдельная статья по формированию и нюансам согласования с представителями заказчика проектных решений, контроль исполнения которых так же входит в компетенции аналитика. Как результат работы аналитика выступает количество внедренных в промышленную эксплуатацию проектных решений. Надеюсь, в этих двух статьях Вы найдете ответы на свои вопросы.
Так же, хотел бы предостеречь от обобщений. В статье неоднократно отмечено, что предложенный подход не может быть рассмотрен как общие правила на всех проектах Ланит и является личной позицией автора. Решение, применять или нет такой подход на своих проектах - остается за Вами.
Смущает широкое использование поправочных коэффициентов. Рекомендую обратить внимание на методику PERT. Пару калькуляторов (для оценки работ аналитиков и программистов) работающих по этой методике можно посмотреть здесь.
Я не настаиваю на своей точке зрения. Если у Вас получается добиваться успеха в проекте без того, чтобы аналитики разбирались в структуре БД - да пребудет с Вами сила. Иногда такое возможно. Например, при использовании Drupal или ОПОРА.УФОС, как платформы для создания ПО, значение понимания структуры БД уходит на второй план. Однако, точно не будет лишним.
К сожалению, несмотря на атакующее отрицание предложенных подходов, ни один из критиков не предложил собственных критериев измерения эффективности аналитической работы. Может поделитесь, в каких "попугаях" измеряются у вас результаты работы аналитика?
Спасибо за наводку. Хорошо дополняет мысль высказанную в начале статьи - обязательно дам почитать своим сотрудникам. Сразу вспомнилась фраза Генри Форда: "Если у Вас появился незаменимый сотрудник, лучшее что Вы можете сделать - это уволить его."
Альбом выходных документов - документ содержащий описание отчетов выводимых на печать (на бумагу), а так же правила построения таких отчетов. Иногда нормативные акты требуют построения отчетов, которые просто нельзя построить на основе имеющихся исходных данных. Поэтому, несмотря на кажущуюся "понятность" отчетов, стоит фиксировать алгоритм представления данных на бумаге.
Пример описания систем классификации и кодирования можете посмотреть здесь.
Ретро-данные - данные которые попали в БД на предыдущих этапах ее существования или данные заказчика которые надо загрузить в БД при вводе системы в эксплуатацию. Зачастую выясняются, что эти данные не соответствуют принятым в БД ограничениям, но загружать/запускать систему надо срочно, ограничения БД снимаются. О необходимости принятия решения по исправлению этих данных (или хотя бы описанию этих противоречий) вскоре забывают. И через некоторое время "внезапно" начинается головная боль, источник которой удается обнаружить далеко не сразу...
Утверждение, конечно, понятно - Путь самурая доступен не всем. Непонятна категоричность, с которой он отвергается. Когда Вы говорите об увольнении - вы говорите на самом деле о страхе увольнения. А я говорю о искренности и объективности оценки своих компетенций. Это другое.
Конечно, перечень материалов избыточен, чтобы каждый мог найти свой путь роста.
IMHO - IDEF0 - от общего к частному. Не считаю, что БД - это не уровень аналитика. Напротив, считаю, что БД - это модель реального мира. И спроектировать такую модель, не представляя как этот мир устроен, это как написать картину с закрытыми глазами. Однако, без понимания того, что будешь использовать в работе - краски или уголь - тоже написать картину не получится.
Почему несправедливой? ВУЗы придумали для формирования массовых специальностей. А в приведенном примере речь шла об уникальной профессии. В определенных отраслях цеховая система обучения не умерла. Иногда выучить учебники недостаточно. Эта тема хорошо раскрывается в диалогах Учителя (Николо Амати) и Ученика (Антонио Страдивари) в фильме "Визит к Минотавру". Рекомендую.
На проектах, которыми я руковожу, нет господ. Как и нет холопов. Это принципиальный момент в организации работы.
Вы пытаетесь анализировать приведенную матрицу, как должностную инструкцию. Это не должностная инструкция - это примерный перечень целей, ориентиров к которым, с моей точки зрения может стремиться аналитик на заказном программном проекте. При этом цели выставлены немного выше, чем требуется.
С моей точки зрения, ведущий аналитик проекта должен являться ключевым интегрирующим звеном в проектировании архитектуры ПО, поскольку он является техническим представителем заказчика на проекте. Однако, к проектированию архитектуры должны привлекаться все технические специалисты по мере необходимости.
Повторюсь, что способность разрабатывать структуру БД для аналитика считаю одной из ключевых компетенций. При этом считаю, в большинстве случаев, нецелесообразным формирование промежуточных моделей (ER и логической), поскольку можно сразу создавать физическую. На моих проектах аналитик создает структуру БД, после чего она проходит рецензирование со стороны программистов - по их замечаниям формируется вариант, который пойдет в эксплуатацию.
Все, что Вы перечислили - это проблемы заказчика и условия программных проектов. Зачастую, это все так. Как решаю эти проблемы на своих проектах, я писал в предыдущих статьях. Однако, эта статья о другом. Здесь я говорю о путях личного совершенствования сотрудника (в рамках одной из ролей проектной группы). Другими словами - Вы говорите о боли пациентов, симптомах болезней, об условиях, с которыми часто встречаешься в больницах. А я - о квалификации определенной категории врачей, которые входят в состав операционной бригады и , что важно для меня, о их мотивах в профессии.
По моему опыту, к сожалению, в комментариях на Хабре слово "словоблудие" очень часто является заменой словосочетанию "я ничего не понял". Если у Вас есть на затронутую тему собственная позиция - Вы можете отразить ее в своих статьях. Удачи.
В статье нет рекомендаций применять матрицу Д. Сиджина на собеседованиях. Для меня она послужила неплохим путеводителем на пути моего личного профессионального роста, высветив темные пятна на которые я не обращал внимания. С моей точки зрения, любая матрица компетенций - всегда только инструмент. И как для любого инструмента, результат его применения очень сильно зависит от целей того, как Вы собираетесь этот инструмент использовать. В частности от того, где Вы собираетесь поставить запятую в предложении: "Топить не стоит помогать".
Бесплатные сертификаты можно получить, разве только, на ресурсе intuit.ru, пройдя тестирование по соответствующим курсам. Я бы предостерег Вас от получения ВСЕХ перечисленных сертификатов. Как бы с водой не выплеснуть ребенка. В случае начинающего аналитика для меня интересны только сертификаты базового уровня по SQL и по BMP (их стоимость минимальна по сравнению с другими сертификатами для аналитика). Именно получение этих сертификатов я рекомендую своим начинающим аналитикам. Все остальные - по желанию и по необходимости.
В 1986 году наверное в каждом военном училище уже был свой собственный вычислительный центр. Выглядел он примерно так, как на добавленной фотографии. Любой преподаватель или курсант мог воспользоваться мощностями этого центра. Герой статьи, будучи курсантом подготовил несколько программ для расчета электронных схем именно на этих машинах. Программировали на Fortran или PL, используя перфокарты или прямо с терминала (ОС Примус). Так что слухи о дороговизне и дефицитности машинного времени сильно преувеличены. Кстати, в некоторых ввузах примерно в это же время стали появляться первые персональные компьютеры серии ЕС-184* (те, что на базе аналога знаменитого процессора i8086).
Спасибо за исследование. Несколько вопросов:
1. Использовался ли на проекте таймтрекинг?
2. Какова медиана и разброс по трудоемкости (time estimate) задач на анализ? задач на разработку?
2 случай — это работа по ошибкам. Группа сопровождения — это первая линия — которая берет на себя задачу регистрации, разбиения (атомизации), сбора сопроводительных материалов и других подготовительных действий до передачи аналитику. При невысоком количестве ошибок от пользователей эти функции может выполнять аналитик.
Как то так.
Однако, замечу, что предложенные процессы не есть истина в последней инстанции. То что работает у нас — не факт, что будет эффективно в ваших условиях.