Мастерская бизнес-анализа

ОЦЕНКА ЗАТРАТ И ТРУДОЕМКОСТИ РАЗРАБОТКИ ПО КАК СПОСОБ УЛУЧШЕНИЯ КАЧЕСТВА ТРЕБОВАНИЙ

Grigory Grin

Предлагаю вниманию читателей статью, написанную Григорием Грином для он-лайн журнала Requirements Engineering Magazine на английском языке и опубликованную 27 февраля 2019г

When the rubber hits the road –  Improving requirements quality by effort estimates.

Мне показалось, что такой взгляд на оценку стоимости и затрат при разработке ИТ — проектов, в русскоязычных публикациях не встречается, и будет интересен нашим аналитикам и руководителям проектов. Перевод сделан мной и согласован с автором. Нэлли Грин 

Введение

Существует ряд критериев качества требований. IREB Syllabus (1) группирует критерии по трем параметрам: содержание, документация и согласованность. Группа согласованность включает следующие три критерия:

• «согласованы»,
• «согласованы после изменений»,
• «разрешены конфликты».

Опыт автора показывает, что обычно невозможно получить надежное соглашение с заказчиком о наборе требований без сопутствующих оценок стоимости / трудоемкости реализации этих требований. Разумеется, такие оценки можно рассматривать отдельно от самих требований, как часть процесса коммерческих переговоров. Но влияние, которое оценки оказывают на требования и их описание, настолько значимо, что автор предпочитает рассматривать оценивание как неотъемлемую часть процесса разработки требований. С такой точки зрения «оценка» может рассматриваться как еще один критерий качества требований.

В представляемой статье рассматриваются взаимосвязи между требованиями и оценками затрат и трудоемкости.
Статья написана для варианта разработки ПО, при котором:

• разработка программного обеспечения контрактная, когда заказчик и подрядчик представляют собой две разных организации с их собственными целями и сложными отношениями между ними,
• контракт с фиксированной ценой fixed-price.

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

Базовая концепция по оценке стоимости разработки ПО

Тем, кто только начинает работу по оценке программного обеспечения, можно порекомендовать отличную книгу по этому вопросу (2):
«Оценка программного обеспечения: демистификация черного искусства» от Стив Макконнелл, которая опубликована в 2006 году.
Ничто из этой классической работы не устарело в течение прошедшего более чем десятилетия. Это обязательное чтение для всех, занятых в отрасли разработки ПО.
Начнем с повторения некоторых основных концепций, представленных McConnell, а затем перейдем к другим темам, основанным на собственном опыте разработки автора статьи.

Сравнительно просто оценить параметры некоторых объективно существующих объектов. Например, высота дерева. Все становится сложнее при оценке чего-то в будущем, чего еще не существует. Для того же дерева — какова будет высота дерева через 5 лет? И еще более сложно, если оцениваемый показатель зависит от усилий, которые будут приложены в будущем.
В отношении разработки ПО обычно оцениваются общие затраты и/или трудозатраты, необходимые для реализации определенных требований или набора требований.

Здесь критически важно различать следующие понятия:
Estimate — Оценка — это прогноз, предположение или мнение. Например: мы можем быть готовы через 4-6 недель.
Target – Цель, которая может быть зафиксирована в плане или ином документе. Например: нам нужно представить релиз до начала сезона отпусков.
Commitment — Обязательство — это обещание (возможно, закрепленное договором). Например: релиз будет представлен к 1 ноября.

Рисунок 1 – и оценка и цель влияют на обязательство

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

Другим важным моментом в определении оценок является то, что они не простые числа, они являются распределениями вероятностей. Если вы скажете, высота дерева через 5 лет составит 4,52 м, вы на 100% уверены? 60% уверены? Какова вероятность того, что дерево вырастет до высоты между 4,5м и 4,6 м? Насколько она отлична от вероятности того, что дерево будет находиться между 4 и 5 м? Всегда гораздо полезнее указать диапазон и задать вероятность того, что целевой параметр находится в этом диапазоне. Например. Я на 90% уверен, что дерево будет между 4 и 5 м.

На приведенном ниже рисунке показано типичное распределение вероятности для оценок ПО. Для любого конкретного значения по оси X имеется соответствующая вероятность на оси Y. Существует естественный нижний предел оценки, ниже которого вероятность становится равной нулю. Но нет верхнего предела (работа может занять любое время, хотя вероятность роста трудоемкости с какого-то её значения уменьшается).

Рисунок 2 Оценка как распределение вероятностей. Рисунок из упоминавшейся книги McConnel-а (Рис.1-3)

Ещё один терминологический аспект, который важно отметить, это разница между (accuracy) правильностью, достоверностью оценок и их (precision) точностью.
Оценка, выраженная в виде интервала, является достоверной, если оценочный параметр действительно находится в указанном диапазоне (от 4 до 5 м в приведенном выше примере про дерево). Точность — это длина интервала (1 м в том же примере). Мы хотим, чтобы наши оценки были в первую очередь достоверными, и лишь потом – настолько точными, насколько это необходимо. Типичная проблема заключается в очень точной оценке, которая не является при этом достоверной. Проект займет 4-5 недель (для проекта, который займет 3 месяца).
Достоверность прогноза может быть оценена только ретроспективно, когда известна действительная величина прогнозируемой переменной. Точность может быть определена априорно.
В книге (2) подробно описываются и обсуждаются очень полезные методы оценки, которые выходят за рамки данной статьи.

Оценки и управление проектом

Для автора основным заявлением книги МакКоннела (2) стало следующее:
«Когда мы сделали оценку и, исходя из этой оценки, оформили обязательство о предоставлении функциональности и качества ПО к определенной дате, мы управляем проектом для выполнения этого обязательства, которое становится ограничением проекта».
Рассмотрим это утверждение более подробно.
У разработчика обычно запрашивают оценки затрат при согласовании нового проекта с клиентом, когда требования выявлены и задокументированы (это для разработчика вход), и в этот момент необходима оценка трудоемкости, чтобы можно было установить цену (выход).
Несмотря на то, что соотношение между ценой, предлагаемой клиенту и внутренней оценкой затрат, может быть различным, ясно, что между ними существует четкая зависимость.
После подписания контракта, когда проект начинается, принятое обязательство больше не может быть изменено (без существенных переговоров).

Рисунок 3 Процесс оценки до подписания контракта.

Предварительная оценка стоимости в интервале 200 -250 тыс. евро, первоначальное предложение заказчику 230 тыс. евро, после согласования контракта окончательно утвержденная цена – обязательство – 210 тыс. евро.
Для проектной команды цена из контракта теперь является обязательной и переставая быть выходом, становится частью входа.

Рисунок 4 Процесс после утверждения контракта – обязательство теперь часть входа, дополнительное требование для проектной команды.

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

Команда проекта может (и должна) выполнять переоценку предполагаемого объема работ и затрат и в начале проекта, и в дальнейшем — в ходе его продолжения. При этом, не достаточно лишь спрогнозировать, что проект с фиксированной ценой в 210тыс евро закончится с затратами в 300тыс евро. Необходимо своевременно обратить внимание на эту ситуацию, и принимать все необходимые контрмеры, чтобы вернуть проект в прибыльный форватер.
Можно, например :
• Целенаправленно выбирать способы решения с учетом минимизации трудоемкости разработки;
•    Активно управлять ожиданиями клиентов;
• Мониторить взаимоотношения с клиентами с целью своевременного формулирования запросов на изменение требований (CR) и получения дополнительного финансирования в случае значительного увеличения трудоемкости проекта;
• В худшем случае, повторно согласовать цену контракта с клиентом.

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

Представление оценки

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

Рисунок 5 Таблица оценок с двухуровневым разбиением функций

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

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

Рисунок 6 Таблица оценок с разбиением на функции и компоненты

Такую матрицу оценок можно сохранять в электронной таблице, например, используя Microsoft Excel. Важно, чтобы эта электронная таблица оценок изменялась синхронно с соответствующими спецификациями требований – каждой версии спецификаций требований должна соответствовать таблица оценок, им должен быть присвоен один и тот же номер версии. Даже без сложного инструмента управления конфигурацией отдельная версия файла оценок может быть сохранена с суффиксом версии в его имени, например. «Project_Estimate_v2.0.xlsx». Различия между версиями можно указать просто путем окраски изменяющихся / добавленных / значений. Это позволяет всем заинтересованным сторонам видеть, как изменились оценки в связи с изменениями требований. Если необходимо, история версий может храниться в одном файле отдельными листами таблицы.

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

Оценки в жизненном цикле управления требованиями

В последней части речь пойдет о сроках, когда процесс оценки должен быть запущен.
Автору часто приходилось видеть подход «водопада» в процессе обсуждения контракта:
• Мы начинаем с анализа. Мы говорим с клиентом, чтобы понять его потребности. Мы записываем все в длинный документ требований. Мы формулируем нефункциональные требования. Мы проводим несколько циклов обсуждений и согласований с клиентом. В конце концов мы получаем спецификацию требований в «согласованном» состоянии.
•Теперь мы оцениваем трудоемкость, основываясь на согласованных спецификациях.
• Дальше мы делаем коммерческое предложение с ценой, основанной на оценке трудоемкости и затрат.
• Наконец, мы надеемся получить подписанный контракт и не можем дождаться начала разработки.
Вместо этого мы часто удивляемся, когда клиент, впервые увидев цену, внезапно меняет свое мнение, исключает половину функций из объема работ, меняет требования, просит альтернативные решения и / или объяснения или, в худшем случае, просто отказывается от проекта или обращается к другому разработчику.
Это происходит, потому что для клиента польза (результат), которую он получит от нашего предлагаемого решения, очень сильно зависит от цены, которую он должен платить за это решение. Если цена слишком высока, начинается переосмысливание важности для клиента сформулированных требований. Это объясняет, почему во многих случаях клиент запрашивает цену (или хотя бы предварительную «оценку»), прежде чем исполнитель сможет провести разумный анализ.

Позиция автора состоит в том, что процесс формирования спецификации требований должен идти параллельно с процессом оценки, и что оценка (в форме электронной таблицы, описанной выше) является дополнительным представлением спецификации, а наличие «оценки» является важным критерием качества требований (для процесса «согласование требований»).
Вряд ли имеет смысл отправлять текст спецификации требований клиенту, если у него нет представления о цене. Конечно, многое зависит от конкретной ситуации. В любом случае рискованно вкладывать слишком много средств в документацию по требованиям, не предоставляя клиенту одновременно возможную цену будущего решения.
Это предполагает более итеративный подход к подготовке контракта, начиная с укрупненных первоначальной спецификации и проекта контракта, с постепенным уточнением того и другого с учетом результатов обсуждений и согласований с клиентом.
При этом, речь идет не только об отношениях с клиентом. Уже отмечалось, что коммерческий результат является одним из наиболее важных ограничений проекта. Следовательно, также ои во внутреннем документе спецификация (текст) и оценка затрат (таблица) проектируются параллельно. Спецификация не может считаться завершенной, если для нее нет оценок трудозатрат. Разработчики должны читать требования через призму оценки их трудозатрат, и они должны проектировать решения с учетом заранее заданных ограничений по трудоемкости.

Заключение

Оценки для реализации требований очень важны в процессе разработки программного обеспечения. Они оказывают влияние на разных этапах:
•   На этапе согласования контракта оценка затрат является базой для цены.
• Во время процесса разработки ПО цена (оценка, ставшая обязательством) является одним из основных ограничений, влияющих на выбор вариантов дизайна и решения.
• Оценка трудоемкости и затрат является предметом регулярных обсуждений между техническими и коммерческими командами, что ведет к лучшему взаимопониманию между ними.
• Важно включать этап оценки уже в самом начале процесса разработки требований, чтобы избежать неприятных сюрпризов, когда уже много усилий было вложено в анализ.
Автор предлагает рассматривать оценки как неотъемлемую часть требований, как их дополнительный атрибут. При такой точке зрения «оценено» может рассматриваться как еще один критерий качества требований (в группе «согласование требований»).

Ссылки
(1) IREB CPRE Foundation Level Syllabus: https://www.ireb.org/en/downloads/tag:syllabi
(2) Steve McConnel, “Software Estimation: Demystifying the Black Art”, Microsoft Press, 2006.

28.02.2019 at 17:10 Оставьте комментарий

Проект по разработке профессионального стандарта «Бизнес-аналитик» УСПЕШНО ЗАВЕРШЁН!

На официальном интернет-портале правовой информации опубликован 12 октября 2018г. «Приказ Министерства труда и социальной защиты Российской Федерации от 25.09.2018 № 592н «Об утверждении профессионального стандарта «Бизнес-аналитик»» (Зарегистрирован 11.10.2018 № 52408).

Здесь же профессиональный стандарт «Бизнес-аналитик» можно посмотреть, распечатать или скачать.

(далее…)

05.11.2018 at 18:16 Оставьте комментарий

Бизнес — аналитики разработали профессиональный стандарт

КАК ЭТО БЫЛО

Во второй половине 2016 года «Бизнес — аналитики начали разработку профессионального стандарта»  — была проведена большая организационная и подготовительная работа.
В конце года было сообщено, что проведена «достаточно интенсивная работа над вопросом продвижения инициативы в Совете по Профессиональным Квалификациям и в Минтруда. В результате инициатива официально признана», разработка профессионального стандарта Бизнес-Аналитик (БА) включена в план Минтруда на 2017 год.
В начале сентября 2017 года появилась информация о том, что структура стандарта предварительно сформирована.

(далее…)

15.08.2018 at 16:34 1 комментарий

А существует ли профессиональное выгорание?

За последние пару лет неоднократно попадались статьи и записи в блогах о случающемся «профессиональном выгорании» и о том, что можно с этим делать.

Всякий раз, натыкаясь на такие тексты, я чувствовала в себе какое-то сопротивление – что это такое, откуда берется, почему в наше время ничего такого не было?

Неужели только потому, что сейчас поток информации столь велик?

Но ведь были другие проблемы – в бооольшом количестве…

Но, как обычно, я списывала свое непонимание этой проблемы на свою же некомпетентность в теме, а ещё на то, в чем меня часто обвиняли – на завышенные требования к людям (правда и к себе тоже).

А написать заметку на эту тему меня побудило интервью в замечательной программе «На ночь глядя» с членом правления Фонда помощи хосписам «Вера» Нютой Федермессер.

Фонд назван в честь Веры Миллионщиковой, создателя и главного врача Первого московского хосписа, мамы Нюты.

Эта женщина всю свою жизнь находится среди людей, дни жизни которых сочтены.  Все, имеющие отношение к этой работе живут под лозунгом «Мы убеждены, что, если человека нельзя вылечить, это не значит, что ему нельзя помочь». И помогают.

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

Ответ Нюты (а ведь она врач!) просто восхитил. Он звучал примерно так (не цитата, но за смысл ручаюсь): не существует никакого выгорания. Если человек любит свою работу и хорошо понимает для чего он ею занимается, то он никогда не подвержен «выгоранию».

И мне очень хочется согласиться и в отношении ИТ специалистов тоже.

03.06.2017 at 14:14 3 комментария

Разработка профессионального стандарта Бизнес-Аналитик включена в план Минтруда на 2017 год

Как сообщил 30 ноября руководитель инициативной группы и руководитель Российского чаптера Международного Института Бизнес-Анализа А. Белин, была проведена «достаточно интенсивная работа над вопросом продвижения инициативы в Совете по Профессиональным Квалификациям и в Минтруда. В результате инициатива официально признана», разработка профессионального стандарта Бизнес-Аналитик включена в план на 2017 год.
В ближайшее время инициативная группа разработает план работы и представит его на обсуждение.

30.11.2016 at 22:50 1 комментарий

Бизнес — аналитики начали разработку профессионального стандарта

18 сентября 2016г Российское Отделение Международного Института Бизнес-Анализа запустило инициативу по разработке Профессионального стандарта «Бизнес-аналитик».

Таким образом пересеклись две основных темы моего блога: бизнес-анализ и ИТ профстандарты.

На первом этапе был проведен опрос: насколько это своевременно и назрело. Ответов было получено не так много, но из тех, кто принял участие, подавляющее большинство (более 2/3 специалистов) высказались за то, что «Бизнес-аналитик уже состоялся как профессия и безусловно нуждается в своем проф. Стандарте».

Уже 20 сентября была создана группа «как открытая площадка для обсуждения вопросов относительно создания Российского Профессионального стандарта Бизнес-аналитик». За полтора месяца к группе присоединились уже 175 специалистов.

Инициаторы создания Профессионального стандарта Бизнес-аналитик провели и проводят серьезную подготовительную и организующую работу:

(далее…)

30.10.2016 at 17:30 3 комментария

Профессиональные стандарты в сфере ИТ – год 2016 — середина

Первое, что важно отметить в сфере профессиональных стандартов в 2016 году, это вступающие в силу с 1 июля 2016 года поправки в Трудовой кодекс РФ, которые предусмотрены Федеральным законом от 2 мая 2015 г. № 122-ФЗ. С этого момента для некоторых видов профессиональной деятельности стандарты станут обязательными.

По поводу этих поправок было много обсуждений, Минтруд выпустил 3 разъяснения относительно применения Закона 122-ФЗ. Относительно отрасли Информационных технологий координатор Комитета по образованию АПКИТ Игорь Кузора сообщил: «Предполагается, что для ИТ-компаний профстандарты в области ИТ будут носить рекомендательный характер.

(далее…)

18.06.2016 at 16:37 1 комментарий

Об истоках водопада -к вопросу о трансформации модели разработки ПО

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

Но мало кто из практикующих разработчиков интересуется истоками, динамикой развития, тем что, откуда и почему появилось.

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

Этот пост – Анонс статьи «ГДЕ ИСТОКИ ВОДОПАДА? ЧИТАЕМ СТАТЬЮ «УПРАВЛЕНИЕ РАЗРАБОТКОЙ БОЛЬШИХ КОМПЬЮТЕРНЫХ СИСТЕМ».

Статья «УПРАВЛЕНИЕ РАЗРАБОТКОЙ БОЛЬШИХ КОМПЬЮТЕРНЫХ СИСТЕМ» была написана Уинстоном Ройсом (Winston Royce) в 1970 году, относительно недавно стала доступна в сети на английском языке, и активно обсуждается и критикуется. Полного перевода на русский обнаружено не было. Автор анонсируемой статьи – Григорий Грин – предлагает перевод статьи Ройса на русский язык и дает свои комментарии, исходя из более чем 25-летнего опыта работы в отрасли – и программистом, и бизнес-аналитиком.

(далее…)

30.04.2016 at 12:08 Оставьте комментарий