Бизнес-аналитика подавай?

[singalen]

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

Ну, то есть, я знаю, почему. Потому что мы хотим колбасить код и больше ничего.

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

Бывает, что лучше всех написать требования можешь именно ты.

Если вы, ребята, профессионалы, то сотрудничайте с людями, с которыми работаете.

Comments

[profuel.livejournal.com]

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

Но вот сегодня, уже в 20+ раз, возникает ошибка в программе, которая возникает из-за того, что написанные разработчиками требования - не читает заказчик, менеджмент. Проекту уже 2 года в моих руках, и год передо мной.

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

[singalen]

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

По второму - у вас и так всё нормально %) Если документация в виде стори в багтрекере вас устраивает, отлично. Всё ненужное не нужно, "это эджайл".

[profuel.livejournal.com]

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

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

Да, пытаемся и мы и нас называть agile.
Мы ведь всего-то хотим, чтобы вместо вопроса - почему это работает не так, была прочитана документация, и если что-то не нравится - были адекватные изменения.
А выходит - и документация хромает, и поток требования/изменений нескончаемый...

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

[singalen]

Это юзерская документация?..

Последняя идея, имнсхо, фейл. Завести документ, в который люди будут писать, что прочитали другой документ, в то время, как они и других документов не желают даже открывать? :D

Люди не читают многостраничные документы. Точка. Если надо строго аппрувить содержимое этих документов - надо доносить его через личное общение. Я об этом.

[profuel.livejournal.com]

не так выразился идею.

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

ps проблема в том, что сейчас начинается очередной мега-проект, в котором уже планирование идет не по самому хорошему пути...

[klizardin.livejournal.com]

>не читает заказчик, менеджмент

более того, обычно они даже начнут возражать, что мол зачем нужно с ними обсуждать очевидные казалось бы вещи. "вот здесь же нужен месседжбокс, а вот тут эдит". надеюсь вы не в такой ситуации.

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


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

ну а пробовали подходить к написанию требований с точки зрения книги "Современные методы описания функциональных требований". Коберна?

[profuel.livejournal.com]

>более того, обычно они даже начнут возражать, что мол зачем нужно с
>ними обсуждать очевидные казалось бы вещи. "вот здесь же нужен
>месседжбокс, а вот тут эдит". надеюсь вы не в такой ситуации.
Увы, ситуация хуже :(
50% - "зачем спрашивать очевидное" Сюда входят и вещи "когда-то с кем-то оговоренные", и вещи "так ведь очевидно, что при удалении надо спросить - "уверены?"
50% - вы не учли всех пожеланий заказчика, о которых мы забыли вам рассказать. А хочет, обычно, наш заказчик - чего-то сверхъестественного.

Последнюю книгу не видел, взял на заметку.

[klizardin.livejournal.com]

книжка хоть и старая, но позволяет планамерно сформировать требования в достаточном объеме и надостаточном уровне как для вас как разработчика так и дать понять о том, что вы будете делать PM-у и заказчику. конечно, далее нужно изучать карнеги))) чтобы уметь тонко допытываться у заказчика, что же именно ему нужно в его манере).

[singalen]

А если на пальцах - что именно он предлагает? :)

[klizardin.livejournal.com]

1. предлагает достаточно хороший формат для написания вариантов использования.
2. рассматривает этот формат формулируя наилучшие подходы к формированию вариантов использования.

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

в том числе формулирует достаточно важное замечание

Разрабатываемая система -- это механизм для выполнения соrлашения между участниками. Варианты использования обеспечивают поведенческую часть этоrо coглашения. Каждое предложение в варианте использования описывает действие,
защищающее некоторый интерес какоrо-либо участника. Предложение может описывать взаимодействие двух действующих лиц или внутренние действия системы, которые она должна выполнять для защиты интересов участников.

Формулирует правила/техники хорошего описания/написания вариантов использования.

Например.

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

Мы делаем это, чтобы разработчики системы и интерфейса пользователя моrли обеспечить соответствие системы этим характеристикам.

* Он определяет структуру списка Действующее лицо/Цель, которая будет использована для расстановки приоритетов и распределения работы.

* Он нужен для разбиения orpoмнoгo множества вариантов использования на пакеты, которые можно распределить между различными rруппами разработчиков.

или

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

цели Обобщенного уровеня -- выше уровня моря, белый вариант использования.

цели уровня подфункций -- это цели, достижение которых требуется для реализации целей пользователей.

[klizardin.livejournal.com]

книга дает этакий базис самого подхода к разработке требований. чем и полезна.

или еще выписанные фрагменты

[klizardin.livejournal.com]

Выявление правильной цели пользователя -- труднейшая вещь в вариантах использования. Сосредоточьтесь на следующих правилах:
* Выявите цель пользователя.
* Используйте от трех до 10 шагов на вариант использования. (т.е. не пишите очень длинных/детальных сценариев)


--Выявление цели пользователя--
Спросите себя, является ли это тем, чего действительно сейчас Хочет от системы основное действующее лицо?

Очень часто начинающие набрасывают подводные варианты использования, думая, что те находятся на уровне моря. Чтобы обнаружить цель более выcoкoго уровня, задайте себе любой из этих вопросов:
* Чеro на самом деле хочет действующее лицо?
* Почему действующее лицо это делает?

[klizardin.livejournal.com]

ну и также этот базис близок разработчику.

[singalen]

Ага, спасибо. Я такие инсайты от Лармана получал, помнится.

[singalen]

А по-моему, это мискомьюникейшн. Они не хотят понять вас, а вы их, если огрублять.

[profuel.livejournal.com]

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

[singalen]

Забей на документы. Проблема не в них, а в том, что вы не выработали приемлемого способа общения, и испорченный телефон (и нервы) вам гарантированны по любому вопросу.

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

Для нас, например, работает подход, когда мы лично ездим к заказчику и получаем от него скоуп на три месяца вперёд :D

[profuel.livejournal.com]

увы, местным менеджерам это не понятно. Им кажется, что проект с оценкой 1 мес делается 3 мес, потому что через неделю появляется еще один срочный проект, потом еще один..... прямо крик души :)

Ваш подход мне нравится, попробуем.

[singalen]

Ну так объясни им :)

[klizardin.livejournal.com]

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

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

в общем, наилучшее решение для меня оказалось уйти и больше не встревать в решения безнес-аналитика.

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

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

[singalen]

Ты не поверишь, в рупе это тоже роли, которые можно совмещать %) Как и везде.

Спрошу по-другому: если мы не желаем учиться выполнять эти роли - то какое моральное право имеем требовать себе хороших требований? :D

[mykola golubyev (from livejournal.com)]

Как только уберут людей типа Business Analyst которые деньги гребут дай боже, все притензии к ним исчезнут. А то сидит такой себе mediator который и в бизнесе только вчера разобрался, с технической стороной даже и не знаком. Очень это заметно в инвестмент банках: реально кто понимает что нужно - это трейдер, говорить он может только с BA, а тот уже как испорченный телефон приходит к тебе.

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

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