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