Лучшие статьи и кейсы стартапов
Включить уведомления
Дадим сигнал, когда появится
что-то суперстоящее.
Спасибо, не надо
Главное Свежее   Проекты

Наталья Носенко

Head of Customer Support | openedu.ru
Подписаться Написать
4 авг 2016 в 13:11
Подробная информация
Комментарии
0
И нам в службу поддержки Национальной платформы открытого образования иногда приходят такие просьбы.

Во всех случаях - клиенту важно знать, что он имеет контроль над своей личной информацией (даже если она не представляет ценности для киберпреступников).

Помимо этого, я для себя выделяю два мотива подобного поведения:
1) "Закрыть гештальт" (для психологического комфорта). Даже если данные не содержат критической информации. По той же причине, по которой расторгают контракт с провайдером мобильной связи, даже зная, что сим-карта в случае неиспользования в течение определенного перида блокируется, а контракт автоматически расторгается.

2) "Снижение риска". Человек полагает, что может иметь место недобросовестное поведение (вашего сервиса или третьей стороны).

Это естественно, что пользователи, несколько раз столкнувшиеся с нежелательным использованием или доступом к их данным, распространяют свой опыт на другие ресурсы. Что они хотят сохранить в секрете от посторонних? Самые разные вещи, в том числе безобидные на первый взгляд.

Бояться могут не вашей недобросоветсности, а абстрактных ситуаций типа взлома третьими лицами.
Ведь что случится в случае гипотетического взлома:
Если аккаунт деактивирован - информация все равно хранится в системе. А если аккаунт удален "насовсем" - данные точно не утекут к злоумышленникам.
10 месяцев назад
0
Там, где одна команда будет писать требования в жестко утвержденном шаблоне на нескольких сотнях страниц, - другая может обойтись списком эпиков и юзерстори, которые надо релизовать.
Но вообще, на практике, в небольшом проекте, который не зажат в рамки корпоративной бюрократии, толщина документа часто зависит от того, а есть ли в вашем проекте уже какие-то артефакты (документы), которыми при необходимости можно дополнить это ТЗ. Например, термины и понятия - важная часть, обеспечивающая точность документа, но ведь где-то уже может лежать страничка в базе знаний, где все эти слова уже перечислены.
Серебряной пули, естественно, нет, и стандартов и шаблонов не один и не два. Но очень полезный и относительно короткий пример - это стандарт IEEE 830-1998 — IEEE Recommended Practice for Software Requirements Specifications (переводы на русский легко гуглятся).

Если какие-то из общепринятых практик вам не подходят - (например, вы непременно хотите описать структуру БД в том же документе, что и функционал для пользователя) - опирайтесь на свой личный опыт и здравый смысл.
Возможно, именно вам подойдет не заморачиваться по поводу названия документа, а просто выписать в столбик основные проблемы и претензии, которые именно у вашей команды были с ТЗ (у постановщика задачи с формулировками, у программистов - с их пониманием), и подумать, в каком формате и какому процессу следовать, чтобы именно эти проблемы закрыть.
>Так может, надо было продумать все как следует на этапе создания ТЗ?
Вообще, наиболее дорогостоящие переделки - именно те, которые возникли на поздних стадиях проекта из-за пробелов требованиях.
10 месяцев назад