вторник, 4 марта 2014 г.

Обзор зарплат системных аналитиков

Системные аналитики – одни из лидеров в сегменте информационных технологий по темпам прироста заработных плат. За год (с февраля 2013 года по февраль 2014 года) зарплатные предложения для них выросли в среднем на 12%, в то время как рынок в целом за аналогичный период – на 8%!

Неправда ли, неплохо? Такую картину нам рисуют в обзоре зарплат на основе вакансий системных аналитиков на портале SuperJob.ru.

вторник, 19 ноября 2013 г.

Cтратегия развития отрасли информационных технологий в РФ на 2014-2020 годы

Не так давно я писал на Хабре о Стратегии развития ИТ-отрасли России на 2014-2020 годы. Собственно, на днях финальная утверждённая версия Стратегии была опубликована на официальном сайте Минкомсвязи. Если убрать привычный скепсис к любой затее Правительства, то с документом стоит хотя бы поверхностно ознакомиться, чтобы понимать, в каком направлении наше государство будет пытаться развивать отрасль информационных технологий в стране.

понедельник, 14 октября 2013 г.

Software Requirements, 3rd Edition

В августе 2013 г. вышло в свет 3-е издание популярной среди системных (бизнес) аналитиков книги Software Requirements, написанной Karl Wiegers в сотрудничестве с Joy Beatty. Новая версия книги была значительно переработана: многие главы переписаны, добавлены новые темы. Сам автор на страницах своего блога упоминал, что со времени выпуска 2-го издания прошло много времени (появилось оно в 2003 г.) - и поэтому настало время обновить информацию, чтобы отразить современные тенденции в индустрии разработки ПО.

Я сейчас не собираюсь проводить анализ нового издания, ведь его я ещё не держал в руках. Однако готов привести список новых глав. Полное же содержание книги можно найти на странице Amazon. Так что каждый сам для себя решит, стоит ли тратить время на чтение новинки. К слову, объём за 10 лет вырос с 457 до 619 страниц! Также буду рад услышать мнение тех, кто уже успел ознакомиться не только с оглавлением и отзывами.

Новые главы
Part II Requirements Development
Chapter 7 Requirements elicitation
Chapter 13 Specifying data requirements
Chapter 18 Requirements reuse
Chapter 20 Agile projects
Chapter 21 Enhancement and replacement projects
Chapter 22 Packaged solutions projects
Chapter 23 Outsourced projects
Chapter 24 Business process automation projects
Chapter 25 Business analytics projects
Chapter 26 Embedded and other real-time systems projects

понедельник, 29 июля 2013 г.

План мероприятий по развитию ИТ-отрасли России до 2018 года

Позволю себе копипаст опубликованной мной новости на Хабре.

15 июля 2013 года Правительство Российской Федерации одобрило план мероприятий («дорожную карту») по развитию отрасли информационных технологий на период 2013-2018 годов.

План мероприятий «Развитие отрасли информационных технологий» состоит из трёх разделов:
  1. общее описание, в котором отражено текущее состояние и перспективы развития российской отрасли ИТ в сравнении с другими странами, а также перечислены важнейшие задачи государства по развитию отрасли ИТ;
  2. контрольные показатели, по которым будут оцениваться результаты работы исполнителей плана;
  3. собственно план мероприятий, с указанием ожидаемого результата, сроков исполнения и ответственных исполнителей мероприятий.




Ссылка на Распоряжение в формате PDF.

четверг, 11 июля 2013 г.

Метод MoSCoW: хорош ли?

Многие системные аналитики знакомы с техникой (методом) приоритезации требований под названием MoSCoW. Данный метод основан на сопоставлении каждому из глаголов Must, Should, Could и Would значения важности (приоритета), которое присваивается требованию, сформулированному с использованием данного слова. Несмотря на то, что данная техника имеет англоязычные корни, русскоговорящие аналитики также используют данный подход: разумеется, заменяя английские слова русскими аналогами. Но настолько ли хорош данный метод, чтобы его можно было смело применять? На данный вопрос для себя я нашёл ответ в статье гуру Карла Вигерса Writing High Quality Requirements, перевод соответствующей части которой я и привожу ниже.

Я должен назвать это требованием


Shall (должен) - традиционное ключевое слово, используемое для определения функционального требования. Функциональные требования описывают поведение, которое система shall проявлять в результате выполнения определённых обстоятельств или действие, которое система shall позволяет совершить пользователю. Некоторые люди возвражат против использования shall, потому что это кажется неестественным. Так и есть - но что с того? На самом деле, это является плюсом. Использование выделяющегося слова чётко отделяет требование от остальной информации в спецификации. Shall служит символом, который сигнализирует о наличии отдельного требования.

Слишком многие спецификации требований изобилуют случайным набором различных глаголов: shall (должен), must (обязан), should (следует), could (может), would (мог бы), is recommended (рекомендуется), is desirable (желательно), is requested (требуется), will (будет), can (может), may (может) и might (мог бы). Многие из этих слов взаимозаменяемы в повседневной речи, но они же могут внести путаницу в письменной спецификации. Читатель должен гадать, существует ли между ними тонкое, но значимое отличие. Обладает ли must отличным смыслом от can? Значит ли might (передаёт ощущение возможности в обычной речи) то же, что и may (передаёт ощущение разрешения)? Я также слышал о правилах, согласно которым shall обозначает требование, в то время как will определяет изложение дизайна, а must устанавливает ограничение. О боже!

Некоторые организации следуют на мной взгляд рискованной договорённости, согласно которой shall обозначает функцию, которая требуется; should определяет функцию, которая является желаемой; may обозначает функцию, которая является необязательной. Здесь возникает две проблемы. Во-первых, тут соединяются две концепции: формулировка намеченной функциональности и относительный приоритет этой функциональности. Во-вторых, информация о важности передаётся с использованием слов, смысл которых схож в повседневной речи.

Я предпочитаю использовать слово shall для определения функциональных требований когда только это возможно. Избегайти применения should, may, might и подобных слов, которые не дают уверенности, что утверждение является требованием. Мой коллега Брайан Лоуренс советует заменять should на probably won't (вряд ли) и потом смотреть, удовлетворит ли это клиента. Вряд ли.

Форма для определения требования "Системе следует (should) сделать X" может быть переделана на форму "Когда случается Y, система должна (shall) сделать X". И вместо использования цепочки shall-should-may для определения приоритетов, я предпочитаю формулировать требования в такой письменной форме:
1. Система должна … [Приоритет = Высокий].
2. Система должна … [Приоритет = Средний].
3. Система должна … [Приоритет = Низкий].

Цель ясного и недвусмысленного общения менее уловима, когда авторы требований применяют смесь практически идентичных по значению глаголов и ожидают, что читатели придут к тем же заключениям, что и они. Честно говоря, я не понимаю возражений против использования shall. Но если вам не нравится это слово, найдите ему замену (вроде must) и применяйте его схожим образом.

вторник, 2 июля 2013 г.

Значит, вы хотите быть аналитиком требований?

Решил разместить в блоге перевод статьи Karl Wiegers So You Want to Be a Requirements Analyst?, который я выполнил более полугода назад.

Карл Вигерс
Process Impact
www.processimpact.com

Аннотация: Все говорят об анализе требований, но не так много сказано об аналитике требований. Каким характером должен обладать человек, чтобы выполнять такую работу? Что аналитики в действительности делают? Что им необходимо знать? Данная статья затрагивает эти вопросы и резюмирует некоторые ключевые навыки аналитика: умение слушать, проводить интервью, анализировать, организовывать семинары, наблюдательность, умение составлять документацию, моделировать и др. Здесь также приведены советы новичкам, пришедших из рядов технических специалистов или пользователей.

Явно или нет, но кто-то всегда исполняет роль аналитика требований в проекте по разработке программного обеспечения. Конечно, официальное название должности может значиться как “инженер требований”, “бизнес-аналитик”, “системный аналитик”, “менеджер продукта” или просто “аналитик”, но кому-то всё равно приходится объединять различные точки зрения, составляя спецификацию требований, и взаимодействовать со всеми заинтересованными лицами. Возможно, наиболее важная часть работы аналитика заключается в том, что он помогает определить разницу между тем, что клиенты озвучивают как свои потребности, и тем, что им на самом деле нужно. Но проще сказать, чем сделать.

Главный посредник

Основная обязанность аналитика требований – собирать, анализировать, документировать и проверять потребности заинтересованных сторон. Являясь главным посредником между представителями заказчика и командой разработки, вы будете играть центральную роль в сборе и распространении информации о продукте, в то время как менеджер проекта – управлять процессом распределения информации о проекте.

Аналитик требований – роль в проекте, не обязательно название должности. Эту роль могут исполнять один или несколько специалистов. Впрочем, на эту роль может быть назначено любое количество членов команды: менеджер проекта, менеджер продукта, эксперт в предметной области, разработчик или даже пользователь.  Тем не менее, талантливый аналитик может существенно повлиять на успех проекта. В своей книге “Оценка стоимости программного обеспечения с помощью модели Cocomo II” (англ.: Software Cost Estimation with Cocomo II, изд. Prentice Hall PTR, 2000 г.) Бари Боэм отмечает, что бывалый аналитик способен сократить на одну треть усилия, требуемые для выполнения проекта, по сравнению с аналогичным проектом, где задействован неопытный аналитик, а проект, в котором участвует высокоспециализированный аналитик, требует вдвое меньших усилий, чем тот, где трудится менее способный аналитик.

Рис. 1 – Аналитик требований налаживает взаимодействие между заинтересованными сторонами заказчика и команды разработки

Задачи аналитика

Баражируя между неопределёнными идеями заказчика и ясной спецификацией, которая будет направлять команду разработки по нужному курсу, аналитик прежде всего должен понять цели, которые ставят пользователи к новой системе. Затем определить функциональные требования и атрибуты качества, которые позволят менеджеру проекта оценить, разработчикам – спроектировать и разработать, а тестировщикам – проверить продукт. Вы можете скачать типовое описание должности аналитика требований по ссылке http://www.processimpact.com/goodies.shtml.

Далее следуют типичные задачи, которые вам предстоит выполнять в роли аналитика.

Определение потребностей бизнеса. Ваша работа начинается с помощи заказчику или менеджеру продукта в определении бизнес-требования к проекту. Первый вопрос, который стоит задать, звучит так: “Почему мы берёмся за этот проект?” Бизнес-требования включают в себя изложение бизнес-целей организации и конечное видение того, как система будет выглядеть и что делать. Чтобы помочь сотрудникам компании изложить свои взгляды, можно воспользоваться шаблоном документа “Образ и границы проекта” (англ.: Vision and Scope Document Template; пример доступен по ссылке www.processimpact.com/goodies.shtml).

Выявление заинтересованных сторон и категорий пользователей. Документ об образе и границах проекта поможет определить важные категории пользователей продукта и другие заинтересованные стороны. Далее вам следует поработать с заказчиком, чтобы выбрать подходящих представителей из каждой категории пользователей, заручиться их поддержкой и обсудить зону их ответственности. Определите тот вклад, который вы желаете получить от представителей клиента, и договоритесь о должном уровне участия от каждого из них.

Извлечение требований. Требования к программному продукту не валяются просто так вокруг в ожидании того, что их кто-то соберёт. Активный аналитик помогает пользователям чётко сформулировать те возможности системы, которые необходимы им для удовлетворения бизнес-целей. Пользователи, естественно, делают упор на функциональных требованиях к системе, так что управляйте обсуждением так, чтобы включить атрибуты качества, требования к производительности, бизнес-правила, внешние интерфейсы и ограничения. Также можно оспаривать допущения, но старайтесь не навязывать пользователям свои собственные предпочтения.

Проведение анализа требований. Ищите требования, которые логически вытекают из запросов клиентов, а также извлекайте те неявные требования, которые они не озвучили, но ожидают, что они будут учтены. Замечайте смутные, неясные слова – причины двусмысленностей и замешательств. Обращайте внимание на конфликтующие требования и области, которые требуют большей детализации. Определяйте функциональные требования на должном уровне детализации для разработчиков, которым предстоит их реализовывать. Проект по созданию веб-сайта, разрабатываемый постепенно небольшой слаженной командой, может иметь поверхностную документацию с требованиями, но сложная встроенная система, которую предстоит передать на стороннюю разработку, должна быть тщательно описана в спецификации требований программного обеспечения (SRS).

Составление спецификации требований. Эффективный процесс разработки требований сводится к формированию совместного понимания и созданию системы, которая решает проблему клиента. Вы ответственны за написание хорошо структурированной спецификации, которая ясно отражает это общее видение системы. Применение стандартных шаблонов для описания вариантов использования и спецификации требований программного обеспечения ускоряет процесс разработки требований, напоминая о вопросах, которые необходимо обсудить с пользователями. Некоторые шаблоны вы можете найти по ссылке: www.processimpact.com/goodies.shtml.

Разработка моделей требований. Вам следует определить, когда полезно представить требования не в виде текста, а в форме графических аналитических моделей, таблиц, математических уравнений, последовательности эскизов или прототипов. Аналитические модели изображают информацию на более высоком уровне абстракции, чем подробный текст. Чтобы увеличить доходчивость и ясность информации, создавайте аналитические модели в соответствии с общепринятыми стандартными нотациями вроде унифицированного языка моделирования (UML).

Проведение проверки требований. Вы должны удостовериться, что задокументированные требования удовлетворяют потребности клиента и что они являются ясными, полными, корректными, достижимыми, необходимыми, отслеживаемыми, недвусмысленными, проверяемыми и т. д. Аналитик – центральный участник экспертной оценки документации с требованиями. Чтобы убедиться, что требования истолкованы корректно, вам также следует просмотреть дизайн, код и варианты тестирования, основанные на спецификации требований.

Расстановка приоритетов требований. Вы будете налаживать взаимодействие и диалог между различными категориями пользователей и разработчиков, чтобы убедиться в том, что нужные люди принимают разумные решения.

Управление требованиями. После того, как базис требований определён, ваше внимание должно будет переключиться на управление этими требованиями и проверку того, что они реализованы в продукте. Помочь в этом смогут коммерческие продукты, специально разработанные для хранения требований.

Возможно, вам захочется отслеживать статус отдельных функциональных требований по мере того, как они переходят от стадии задумки к проверке их реализации в продукте. Собирайте среди команды разработчиков отслеживаемую информацию, чтобы сопоставлять отдельные требования с прочими элементами системы. Эти данные поспособствуют управлению изменениями, вносимыми в базисную версию требований, в рамках процесса и инструмента контроля изменениями.

Необходимые навыки

Эффективный аналитик сочетает в себе способности взаимодействовать, участвовать в командной работе, налаживать межличностное общение и знания технического и бизнес-контекста, а также подходящие для данной работы личные качества. Терпение и подлинное желание работать с людьми являются ключевыми факторами. Ниже приведены 10 навыков, необходимых для вашего успеха.

1. Умение слушать. Активное слушание затрагивает моменты устранения отвлекающих факторов, поддержания открытой позы и визуального контакта, а также пересмотра ключевых моментов для того, чтобы подтвердить ваше понимание проблемы. Вы должны схватывать налету то, что говорят люди и, кроме того, читать меж строк, чтобы выявить недосказанное. Изучите, как ваши коллеги предпочитают общаться, и попытайтесь избавиться от субъективного фильтра, чтобы ваше понимание соответствовало тому, что говорят клиенты. Следите за предположениями, которые лежат в основе того, что вы слышите от других, и вашего собственного представления.

2. Умение проводить интервью и задавать вопросы. Большинство требований добываются в ходе дискуссий, поэтому аналитик должен уметь задавать правильные вопросы. К примеру, естественно, что пользователи акцентируют внимание на нормальном, ожидаемом поведении системы. Однако, любой программист знает, насколько много кода необходимо написать, чтобы обработать исключительные ситуации. Задавайте вопросы из разряда: “Что должно произойти, если...” или “Может ли такая-то проблема в принципе возникнуть?” – так вы сможете определить, как система должна реагировать на неожиданные исключительные ситуации. С опытом вы постигнете искусство задавать вопросы, которые раскрывают и проясняют неопределённости, разногласия, предположения и неупомянутые ожидания. Дональд Гаузе и Джеральд Вайнберг описывают “контекстно-независимые вопросы” в книге “Исследуя требования: качество прежде дизайна” (англ.: Exploring Requirements: Quality Before Design, изд. Dorset House, 1989 г.).

3. Аналитические способности. Вам нужно будет научиться действовать на различных уровнях абстракции. Иногда вам придётся от информации высокого уровня перейти ниже и углубиться в детали. В иных ситуациях вам нужно будет перейти от конкретной потребности пользователя к множеству требований, которые относятся к целому классу пользователей. Критически оценивайте информацию, полученную из разных источников, чтобы разрешать конфликты, отделяйте желания пользователей от их потребностей и различайте идеи и требования.

4. Организация групповой работы. Семинары по сбору требований являются общепринятым приёмом. Для их успешного проведения необходим нейтральный куратор. Вам потребуются хорошие навыки в задании вопросов и умении наблюдать, чтобы помочь группам достичь чувства доверия и разрядить атмосферу зажатости, иногда возникающую между представителями бизнеса и техническими специалистами. В книге “Требования через взаимодействие: семинары для определения потребностей” (англ.: Requirements by Collaboration: Workshops for Defining Needs, изд. Addison-Wesley, 2002 г.) Эллен Готсдинер приводит значительное количество советов для кураторов рабочих встреч.

5. Наблюдательность. Если вы добросовестно наблюдаете за тем, как пользователь выполняет свою работу или пользуется приложением, вы можете отследить тонкости, которые он мог не упомянуть, и таким образом обнаружить новые области для обсуждения требований.

6. Составление документации. Основным результатом вашего труда будет составленная спецификация требований, которая предназначается для клиентов, маркетологов, менеджеров и технических специалистов. Для выполнения этой задачи вам потребуется отличное владение английским или иным языком. Стремитесь к ясности, избегайте двусмысленных слов и фраз, грамматических ошибок и обилия идиоматических выражений.

7. Организаторские способности. Вам придётся иметь дело с широким спектром разрозненной информации, полученной в результате извлечения и анализа требований. Структурирование всех быстро меняющихся частей в связное целое, наряду с терпением и упорством требуют выдающихся организационных способностей.

8. Моделирование. Такие нотации, как уже давно известные потоковые диаграммы, модели структурного анализа (диаграммы потока данных, “сущность-связь” и пр.), и современные нотации вроде унифицированного языка моделирования (UML) должны быть включены в снаряжение каждого аналитика. Некоторые из этих приёмов будут полезны при взаимодействии с пользователями, другие – с разработчиками. Вам часто придётся объяснять другим заинтересованным лицам значение этих диаграмм и то, как их читать. И тогда вы поймёте, что эти инструменты весьма пригодны для представления информации, даже когда вы не обсуждаете компьютерные системы.

9. Межличностное взаимодействие. Вам необходимо организовать работу так, чтобы люди с конкурирующими интересами могли работать вместе. Вам также следует чувствовать себя комфортно, общаясь с представителями различных должностей, находящихся на любом уровне служебной лестницы. Вам, возможно, придётся работать с командами, члены которых разделены по географическому, временному, культурному или языковому признаку.

10. Проявление творческих способностей. Аналитик далеко не писарь, который фиксирует всё, что скажет клиент. В своей статье “Эврика! Почему аналитику следует изобретать требования” (англ.: Eureka! Why Analysts Should Invent Requirements, изд. IEEE Software, июль/август 2002 г.) авторитет в области анализа требований Джеймс Робертсон заявляет, что лучшие аналитики требования именно предлагают. Аналитик может предложить инновационные возможности продукта, представить новые рынки и возможности для бизнеса и подумать о способах, как можно удивить и воодушевить своих заказчиков. Поистине значимый аналитик находит творческие пути для удовлетворения нужд пользователей, о которых они даже и не подозревали.

Знание предметной области, бизнеса и задач

Один лишь энтузиазм не проведёт вас далеко в сборе требований: широта знаний, накопленных опытным путём, – единственный путь отточить ваши способности. Закрепите для начала понимание современных техник разработки требований и того, как они совмещаются с различными жизненными циклами разработки программного обеспечения. Аналитику следует понимать, какую роль разработка и управление требованиями играет в жизненном цикле продукта. Глубокое понимание таких дисциплин, как управление проектами, управление рисками и обеспечение качества может помочь избежать ситуаций, когда связанные с требованиями проблемы подрывают устойчивость проекта. В реальных проектах вы выиграете от знания концепций управления продуктом и способа, в соответствии с которым корпоративные программные продукты позиционируются и разрабатываются.

Знания прикладной области, которые уменьшают недопонимания с пользователями, являются мощным активом для успешного аналитика. Аналитик, который разбирается в прикладной области, часто обнаруживает несформулированные предположения и неявные требования. Он также подсказывает пользователям пути улучшения их бизнес-процессов. Такой аналитик иногда предлагает ценную функциональность, о которой пользователь даже и не задумывался. И наоборот, он может обнаружить украшательства, т.е. избыточную или ненужную функциональность, что не сделал бы тот, кто не знаком с проблемной областью.

Не обученный, а воспитанный

Поскольку не существует признанной образовательной программы или описания должности для аналитика требований, большинство из них имеют различный профессиональный опыт. Если вы переходите к анализу, будучи ранее пользователем системы, вам потребуется дополнить свои всесторонние знания бизнеса и производственных условий, пройдя обучение в области программной инженерии, и научиться взаимодействовать со своими техническими коллегами. Вам также необходимо будет осознать, что ваш опыт пользователя не является всеохватывающим, что не следует концентрироваться исключительно на интерфейсе пользователя и что не нужно игнорировать мнения истинных пользователей новых продуктов. С другой стороны, если вы являлись в прошлом разработчиком, вам нужно расширять понимание области бизнеса и не злоупотреблять техническим мышлением и жаргоном.

Каким бы ни было профессиональное прошлое, обучение необходимым навыкам (таким, как восприятие на слух, проведение переговоров и организация групповой работы) и их практическое применение помогут новоиспечённому аналитику любого происхождения раскрыть неозвученные доселе желания пользователей.

Приложение: Сбор данных

Попробуйте использовать следующие приёмы, чтобы собрать сведения о требованиях:
  • проведение интервью;
  • организация рабочих встреч;
  • анализ документации;
  • проведение опросов;
  • посещение веб-сайта клиента;
  • анализ бизнес-процессов;
  • анализ потока работ и задач;
  • изучение списка внешних событий и откликов системы;
  • анализ конкурентных продуктов;
  • осуществление обратной разработки существующей системы;
  • создание ретроспективы прошедших проектов.

понедельник, 24 июня 2013 г.

Конференции для аналитиков

В своём первом посте блога я решил опубликовать подборку конференций для системных (бизнес) аналитиков, которые проходят на территории России и бывшего СНГ. Думаю, что для начинающих специалистов это может быть полезно.

Конференция для IT аналитиков ReqLabs

Конференция для бизнес- и системных аналитиков, посвященная дисциплине сбора и анализа требований в проектах разработки и поддержки ПО. Пожалуй, она была самой известной и масштабной конференцией в своём роде до 2013 г. - в последний раз формат был изменён на онлайн-вебинары, а количество докладов резко сократилось. Организатор: Luxoft Training.

Международная конференция по системному и бизнес анализу Analyst Days

Относительно молодая конференция, которая была проведена пока что лишь дважды (в 2012 г. в Минске, в 2013 г. в Санкт-Петербурге). Организована компанией "Лаборатория тестирования".

Летний аналитический фестиваль ЛАФ

Ежегодный летний двухдневный фестиваль системных аналитиков, который в 2013 г. проводится уже в четвёртый раз. В первый день проходит непосредственно конференция с докладами и мастер-классами, а второй день посвящён общению участников в свободном формате.

Дополнительно

Ещё стоит отметить ресурс Айти-Событие, на котором можно узнать график проведения и описание всевозможных мероприятий, относящихся к области высоких технологий в целом.