Доклад livrecon 2019 "Проблемы сбора требований"

25 - 26.05.2019 прошла конференция "LivreСon", на которой  авторы  издательства Livrezon рассказывали о своих книгах и исследовательских темах.

Доклад является обзором на одну из глав моей книги.

Здесь будут представлены тезисы из доклада.

Вместо введения 

Напомню, что ТЗ - это исходный документ на проектирование технического объекта. Поскольку ТЗ -это исходный документ, то от него зависит насколько качественным будет итоговый продукт.

Например, сейчас сложно представить чтобы отсутствовала техническая документация на проект дома, а тем более АЭС.

Но часть ИТ проектов до сих пор создаются без ТЗ или с низкокачественным ТЗ.

Собирая информацию по проблемам написания качественного ТЗ я обнаружила более 10 проблем связанных с этапом сбора требований.

На данном этапе наиболее часто встречаются следующие 4 проблемы:

• “Поди туда не знаю куда”
• ”Домино”
• ”Вавилонская башня”
• ”Молчание НЕ золото”

Рассмотрим эти проблемы на реальных кейсах.

Начнём с первой проблемы. 

Проблема 1 - “Поди туда не знаю куда” 

Проблема: Заказчик не может сформулировать для чего ему автоматизация. 

Результат: проблема заказчика не решается, требования меняются от Демо к  Демо, версии ТЗ постоянно меняются, члены команды не знают актуальной версии и внедряют не то.

Разберём историю о неэффективном использовании 2 млн.рублей.

ТОП-менеджеры компании позвали своих ИТ-шников и просят внедрить процесс электронного документооборота на всём предприятии.

ИТ-шники же хотят всё сделать правильно. Поэтому отправляются “в поля” узнавать как работают и взаимодействуют подразделения.

Приходят в бухгалтерию.

Разработка: Что Вы хотите от СЭД?

Бухгалтерия: У нас уже есть электронный документооборот! Через Контур.Экстерн мы отправляем отправляют отчёты в налоговую

Разработка: Это весь Ваш документооборот?

Бухгалтерия: Нет. Ещё мы взаимодействуем с контрагентами. Правда часть из них это бумажные носители. 

Разработка:Много контрагентов присылают документы на бумажном носителе? 

Бухгалтера: Всего двое. 

Разработка: Как регламентирована работа с такими контрагентами?

Бухгалтерия: Ой, в  регламенте такого нет.

Разработка:  Что Вы понимаете под документооборотом?

Бухгалтерия: Обмен документами между государственными органами  и контрагентами.

Идём в канцелярию - ситуация аналогична.

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

Какие были допущены ошибки:

1)При получении заказа у ТОП-ов не уточнили цели внедрения документооборота: они хотели сократить людей? Вытащить аналитику? Организовать тотальный контроль в режиме онлайн? Это просто модно и они хотят быть как все? Или просто акционеры дали деньги именно на этот проект и деньги необходимо освоить?.

2)  Разработчики спрашивали о целях проекта у пользователей, а не у ТОП-ов. Пользователи мыслят в рамках своей узкой функциональности без картины в целом.

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

Решение:

Проведение экспертизы бизнес-процессов. Один из способов,чтобы у заказчика появилось представление “куда идти”.  Построение моделей As Is и To be. 

Риски:  

-возможно компании ваша система окажется не нужна и  к изменениям заказчик будет просто не готов. 

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

Кейс 2 - “Вавилонская башня” 

Проблема: заказчик и разработка говорят на разных языках

Результат: Неверно понятный заказчик, некорректно написанное ТЗ, переделывание ПО, увеличение времени проекта. В проектах с такой проблемой о которых мне известно, время разработки из-за недопонимание удлинялось от 4 дополнительных человека-часов до 2-х месяцев. 

Теперь представим Клиента из ЖКХ со специфической терминологией. 

Аналитик приходит к инженеру, который должен заносить в систему новые объекты обслуживания. Необходимо выяснить, что необходимо улучшить. Инженер с удовольствием рассказывает какие есть особенности подключения гаражей к МКД: отдельная схема «‎запитки» от столба, схема «‎запитки» от МКД в зависимости от подключения к сети. Но если ИТ-шники начнут спрашивать о том, как это лучше реализовать в программе, то в лучшем случае им ответят, как это реализовано в текущей версии без детализации и оценки.

Решения:

1)Объяснять на схемах и картинках.

2)Собирать требования через пользовательские сценарии. Наблюдать за действиями пользователей . 

3)Перекрёстный допрос.

Проблема 3 - “Домино”

Проблема: Разработчики не знают о смежных процессах, а Заказчик не догадываются, что об этом надо рассказать 

Результат: ломается процесс, ломаются смежные процессы, т.к. до написания ТЗ не были зафиксированы смежные процессы и не оценено влияние разработки на них.

Пример снова из ЖКХ

Хотели автоматизировать передачу показаний из Личного кабинета(ЛК) в биллинговый комплекс. 

Ранее показания выгружались единым файлом из ЛК и в ручном режиме загружались в биллинг.

Запустились.

Выяснилось, что по части территорий нельзя грузить показания из ЛК, т.к. там есть предписания суда, что необходимо грузить показания из других источников.

Отключили загрузку по списку территорий.

Попробовали снова рассчитаться.

И тут оказалось:

1)Если показания не в состоянии “передано”, то клиент при просмотре электронной квитанции не видел показаний, по которым был произведён расчёт. 

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

В результате доработку откатили.

Потом месяц дорабатывали сервисы самого ЛК.

В результате:

а)Пришлось делать ещё 2 доработки стоимостью примерно 200 т.р.

б)Компания понесла имиджевые потери и получило предписание от ГЖИ

г) Клиентский сервис 2 месяца отвечал на жалобы клиентов

Решение (слабые):

1)Перекрёстный допрос не только заказчиков, но и разработчиков ПО на предмет, а как там всё устроено (Куда? и Почему?).

2)Построение схемы движения данных

Проблема 4 - “Молчание НЕ золото” 

Проблема:Заказчик не хочет общаться, плохо идёт на контакт.

Результат:

1. Создали продукт, который вообще или частично не соответствует ожиданиям заказчика.
2. Попали в “Чёрный список”, проели весь бюджет и даже ушли в минус.

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

Разберём на примере:

Разработчик  выиграли в тендере по внедрению BI, подписан контракт. Проект кажется подъёмным, клиент адекватным. Всё круто!

До первого визита к заказчику с уточняющими вопросами.

Например, Вы читаете техническое задание, у Вас появляется вопрос по блоку  “Расчёт затрат на инвестиционный проект” и обращаетесь с просьбой уточнить расчёт формирования себестоимости. Одна служба вопрос игнорирует, а вот другая говорит: “В ТЗ всё написано. Читайте ТЗ!”. И так с каждым вопросом.

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

В результате, когда показали финальный продукт Заказчик был в ужасе! Поругался на разработчиков матом и начал рассказывать, где не правильно и как должно быть.

Решения:

1) Презентовать сырой продукт. Тогда все начинают носиться и выдавать свои требования, понимание конечного продукта.

Данный метод не применим при “пилоте” и с компаниями, для которых Ваш проект не сильно важен, поэтому такой экстремальный метод надо применять аккуратно.

Дополнительно самой Разработке надо иметь железные нервы, т.к. исправления придётся вносить в авральном режиме.

Также есть имиджевые риски.

2) Эскалация проблемы до вышестоящего руководства. Применима только в тех случаях, когда Заказчик заинтересован в проекте и реально может воздействовать на коллектив. В случаях, когда проект навязан сверху и ни у кого из Заказчиков нет желания  помогать или Руководство Заказчика считает, что ИТ-шники и без него все решат, это решение не работает.

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

В завершении:

Сейчас были разобраны 4 проблемы из этапа сбора требований, но выявленных проблем более 10. А ещё существуют этапы написания, согласования ТЗ, а также внесение изменений в проект.

Начиная своё исследование я много слышала жалоб Разработчиков на Заказчиков ПО и Заказчиков на Разработчиков. 

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

Поэтому прошу читателей, если у Вас есть примеры:

- проблем, которые у Вас возникали при создании ПО до начала реализации.

- проблем, которые возникли из-за упущений ТЗ и предпроектного анализа.

- решений, которые Вам помогли решить названные проблемы

Прошу мне писать по адресу akashevavi@gmail.com.

Я возьму Вас интервью по Скайпу или телефону, которое занимает 40 минут.

Затем Вам пришлю текст интервью для согласования.

Если Вы не хотите “светиться”, то прошу в теме письма указывать слово “Аноним”, тогда при публикации Ваших примеров авторство будет за Анонимом.

Респонденты, чьи примеры войдут в книгу, то:

1. В книге под Вашим примером будет ссылка на Вас.
2. Книга для Вас будет в подарок.