Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Мухо

Страницы: « 1 2 3 4 5 »
31
не могу не согласиться. я, конечно, несколько утрировал пассаж про "обвинения". у нас, как у аффилированного МТС разработчика OSS/BSS решений так происходит постоянно :) но это наша специфика работы.
я не совсем корректно выразил мысль - "обвинениям в кривомозгости" свойственно возникать, когда скоуп проекта бесконтрольно расширяется и сроки начинают срываться. у нас так довольно часто происходит.
в принципе, "обвинения" - это элемент кранча, который легко можно устранить.

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

32
аналитик виноват когда себя поставил в команде как козёл отпущения  :)
по теме же, вы всё смешали в одну большую кучу, где перемешались заказчики и программисты, в то время как существуют разные документы, предназначенные для:
1. заказчика
2. для имплементации бизнес-логики в системе.
3. сношений с тестированием
4. приёмок и прочего.
любой документ имеет цель: согласовать бизнес логику проекта, согласовать архитектуру разрабатываемого решения, согласовать низкоуровневые архитектурные моменты как методы и интерфейсы взаимодействия, сценарии приёмочных тестирований и прочее.
общая мысль следующая: каждый документ имеет цель, и от неё нужно плясать. для заказчика писать доки в удобном для него формате, для разрабов - в удобном им формате. никогда не будет одного документа, эффективно читаемого как заказчиком, так и разработкой, потому что и те, и другие имеют под собой инкрементную природу (количество согласующих имеет свойство постоянно увеличиваться с обеих сторон)
вопрос формализации обсосан очень и очень много раз. может, конечно, я не правильно понял вопрос темы.

а что до взаимных обвинений в кривомозгости, то я с вами не соглашусь - в ЛЮБОМ сложном проекте с внешним заказчиком, наступает момент таких обвинений. он обусловлен рамками реализации и бюджета. заказчик хочет побольше, а денег заплатить поменьше, подрядчик же, наоборот. обвинения - это элемент торга :-) вариант кранча, если в терминах теории переговоров.


33
не знаю как в Росии, но в Украине аутсорсеры средней руки не очень любят становиться частью подобных сообществ как TMForum. Frameworx - своего рода сбор всех вертикальных решений в одном месте.
согласен.
Для начала, rave, надо бы разобраться с e-tom на которой построен ngoss. Павел дал отличную книгу.
я БА в ОСС/БСС решении для МТС. мы никак не используем фреймовркс. не совсем понимаю применимость таких концепций и подходов в крупных системах. как правило, в них БП уже отлажены и дорабатываются под нужды конкретной временной перспективы. а это почти всегда доработки существующего решения. на мой взгляд и опыт, е-томы и нгоссы используют отнюдь не в разработке, а в стратегическом планировании разные высокосидящие ПМы. потом эти планы и схемы падают на разработчика в виде очередного геморроя "сделайте мне счастливо".

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

35
...к нам постучались с предложением внедрения кредла. интеграции с TFS и VS я так понимаю, нет?
вещь в себе получается.

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

37
Мухо,

а Вы случаем не из ПС в Ситроникс ушли?
что такое ПС?)
я в СТС ушёл из CBS)

38
голову сломал с приблудой TeamSpec - специализированная надстройка в ворде для управления требованиями в ТФС.
это конечно ад, с ней работать, но, ежели нет денег на Калибер или ещё какую промышленную СУТ, то работать, в принципе, можно.
приблуда соединяется с тфс, позволяет размечать документ на артефакты, синхронизируется с тфсом. месяц с ней ковырялся, в итоге в понедельник к нам в ситроникс приезжают IBM показывать свой СУТ. потом Калибер посмотрим :)

39
я за Иваново. из Москвы нетрудно добраться.
я, как уже говорил, с собой несколько коллег возьму из Ситроникса. будем про специфику телекома рассказывать :)

40
А может быть сделать тематику конфы в этому году: Работа аналитика в разных предметных областях?!
Т.е., чтобы люди поделились, как работается Аналитику в разных областях: банки, ретейл ..., м.б. кто-то расскажет про БП в этих областях ...
могу попробовать сделать доклад про телеком. в этом году буду участвовать. ещё и коллег подобью.

41
уточняйте gross/net :)

42
коллеги, не забывайте, что это "требования вакансии". в реальности наверняка послабее требования будут :)
насколько я понял, им нужен аналитик пэпээрить документы на английском(intermediate) и решать технические вопросы со специалистом(upper intermediate). адвансед нужен, если аналитику так же придётся рассказывать красивые сказки заказчику :)
а для технических вопросов intemediate вполне себе. к тому же, общаясь с носителями человек быстро наберёт вес в англомове. я, вот, два года назад перестал с носителями общаться и потерял навыки общения. зато грамматические ошибки остались на том же уровне :D

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

44
интересная вакансия. наверное, английский нужен на хорошем уровне? :)

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

Страницы: « 1 2 3 4 5 »