Недавно я взялся делать газон на даче. Очистил территорию от сорняков, прошёлся пару раз культиватором, расставил маяки высоты и натянул разметочный шнур. И начал выравнивать горизонталь. Процесс дошёл до некой точки и вдруг я понял что я выбрал слишком высокий уровень для газона и мне не хватит земли для того, чтобы выровнять все неровности участка. Этого можно было бы избежать, если бы изначально я не погнался за красотой боковой линии и реально оценил бы объём земли, который мне понадобится.
Казалось бы, при чём тут управление IT отделом?
Собственно, речь пойдёт о стоимости ошибки, возникающей на различных этапах жизненного цикла проекта. Вернусь к рассказу о своём газоне. Из доступных вариантов решения проблемы у меня есть альтернатива из трёх вариантов:
- Пройти всё ещё раз культиватором и начать работу заново (затратить время)
- Купить машину грунта и как бы опять начать заново (затратить деньги)
- Придумать изогнутую линию лужайки и попытаться изобразить из этого какой-то дизайн, но с этим категорически не согласна жена (заказчик)
Вот теперь собственно перейдём к сути.
Самые дорогие ошибки — это ошибки проектирования, или ошибки сбора требований. Если требования не собраны, собраны не верно или не полно — есть риск понести затраты в размере до 85% бюджета разработки [1]. На такие ошибки всегда приходится тратить очень много времени и средств. Потому что кроме стоимости устранения ошибки в требованиях необходимо ещё доработать то, что уже, казалось бы, работает. В самых критических случаях, как в моём примере с моим газоном, ошибка как раз критичная, потому что требует изменения всего проекта: снести и переделать (потратить время разработчиков = деньги компании), купить внешнюю помощь (и опять затратить время и деньги) или попытаться доказать заказчику, что он хотел именно то, что описано в требованиях (с вероятностью близкой к 146% этого не получится).
Почему же получается так, что возникают ошибки на этапе сбора требований? Постараюсь дать свою оценку этой проблемы.
- Недостаточная компетенция бизнес-аналитика (постановщика задач). Это связано с тем, что часто бизнес-аналитик выступает только в роли передающего звена между конечным пользователем и разработчиками, при этом сам не разбирается в предметной области и не может предложить лучших вариантов решения или не может до конца понять проблему пользователя. Вероятность таких ошибок можно резко снизить если дать бизнес-аналитику или постановщику задач пройти программу обучения для рядовых сотрудников или производить сбор требований из нескольких источников.
- Неспособность пользователя сформулировать проблему. Это встречается у новых сотрудников, либо у тех, кто мало работает с системами автоматизации. Такие пользователи не могут сформулировать свои требования в терминах системы, а оперируют только понятиями своей предметной области. Такие ошибки легко устраняются обучением и инструкциями.
- Спешка. От таких задач лучше стараться отгородиться и дать им полежать. Потому что такие запросы на доработку чаще всего возникают после какого-то события (как говорят, «жареный петух клюнул») и заинтересованный пользователь на волне «энтузиазма» будет продавливать свои запросы в первую очередь, оперировать такими понятиями как «нужно было вчера», «на контроле у директора» и т.д. В условиях постоянного давления со стороны такого пользователя высока вероятность сбора неполных или некачественных требований, т.к. можно не учесть смежные подсистемы или бизнес-процессы. Как вариант устранения — перевод таких задач из разряда «срочные и важные» в разряд «несрочные неважные», потому что чаще всего так и есть. Пожар сам собой потухает через пару дней.
- Незнание архитектуры работающего решения. В принципе, из всех выше перечисленных это не самая серьёзная проблема и решается просто — достаточно провести для бизнес-аналитика краткое обучение по системе. Но проблем такие ошибки могут принести немало, т.к. велик риск сильно испортить уже работающий отлаженный модуль или задублировать имеющийся функционал. С точки зрения затрат времени\ресурсов оба варианта плохие.
Вкратце, вот так.
Будьте внимательны при разработке требований, берегите свой бюджет!
1. «Разработка требований к ПО», К.Вигерс, Дж. Битти, Microsoft Press, 2014.
Добавить комментарий