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

×


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

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


Сообщения - AlexTheRaven

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 »
46
Мое скромное имхо:

"Компания имеет сертификат  CMMI level N" не равно "Компания имеет уровень зрелости CMMI level N"

А если этот сертификат получен год, два и более назад, то разница может быть очень существенной.
+1

Сертификация не значит, что работа реально построена по CMM (равно как по ISO, ГОСТ, СНиП, СанПиН, ГСН, ВНП, ВН, ГЭСНр, ЕНиР и т.д. :) ). Тем более, то, даже если CMM 3+, процессы описаны и зафиксированы, и даже развиваются, совсем не означает, что эти процессы работают эффективно и приводят к хорошему [финансовому] результату.

Что-то я не слышал, чтобы Microsoft, Google или Oracle сертифицировались на CMM. Потому что им эти ритуалы (сам понимаю, что назвать CMM ритуалами очень спорно) и PR не нужны, они и так хорошо работают.

Поэтому и хочется информации о практике :) . Может быть, с авторитетным-авторитарным архитектором, который концентрирует на себе принятие всех решений о функциональности и архитектуре (а то ещё и и управленческих), работа объективно идёт эффективнее, а проекты - быстрее и [финансово] успешнее? За счёт того же, за счёт чего и при индивидуальном программировании, например?

47
А Вы что-нибудь знаете о том, как устроена разработка у больших и успешных, наподобие Microsoft, Google, Oracle, SAP? Autodesk, Corel, Borland, Symantec, Novell, Electronic Arts и других "богатых и знаменитых"? Какие у них используются методологии, есть ли там роль "авторитарный суперархитектор"?

Если честно, интересует в некотором смысле инсайдерская информация, а не та, которая уходит в прессу. Может, Вы сами там работаете? Или знаете кого-нибудь, кто там работает, и можете спросить?

48
Из средств - мы пользуемся BMC Remedy, но и freeware service desk - множество. Только не питайте надежд "вот внедрим систему - и сразу настанет порядок". Лучше идти от налаженных неавтоматизированных процессов к налаженным автоматизированным, чем от непонятно чего к непонятно чему автоматизированному.

---

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

Я бы даже сказал, что уже 38 лет как есть такая замечательная система - электронная почта. Для начала её хватит. Просто пользуйтесь принципами "всё через почту", "нет письма - нет работы" и "не ответил на письмо в течение 15 минут в присутственное время - косяк".  Ещё есть [электронные] таблицы: по вертикали - ФИО, по горизонтали - дата, в клеточках - что делает.

И уже сможете вести какую-то организацию и учёт работы, 5 человек - не 500, клиентов - тоже, наверное, не 1000, много ли надо? Не говоря уже о том, что сейчас на письма можно навешивать всякие флажки, теги, напоминания.

Просто кто-то один должен взять на себя работу администратора/координатора.

Сразу CMM 5 стать нельзя. Нужно сначала поработать CMM 1 ad hoc ("каждый раз - как получится"), выработать собственные стандартные процессы и хорошие практики, прийти к тому, что их надо записать, и что надо сделать так, чтобы все играли по этим правилам.

Вы сейчас можете начать рисовать абстрактные бизнес-процессы. Но если у Вас (или у кого-нибудь, кто сможет Вам об этом рассказывать минимум 1 час в день) нет опыта работы 5+ лет в системной интеграции и тех. поддержке на уровне как минимум руководителя направления - эти бизнес-процессы вряд ли будут полезны. Придётся накопить собственный опыт. И по мере накопления постепенно автоматизировать.

Да, изучить ITIL/ITSM и перерисовать его своими руками в ARIS (я говорю о методологии и нотации, и только во вторую очередь - средстве) - очень полезно. Но теория практику, собственный опыт и специфику не заменяет.

49
Почему Вы считаете, что цена несправедлива или сроки преувеличены? Может, это просто "антикризисный костинг", призванный любой ценой снизить затраты в краткосрочном периоде?

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

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

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

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

Есть ещё одна опасность. Начнёте "отжимать" своего вендора/франчайзи - он может начать делать дешевле, с меньшим "заделом на перспективу", "запасом прочности", с худшей архитектурой, не таким тщательным тестированием. Худшей мотивацией и качеством, в конце концов. И это может стать "плевком в будущее".

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

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

Вот для этого и нужен реальный уровень CMM :) . Хотя многие IT-гики считают, что IT нельзя оценить и некорректно оценивать.

50
Эдуард, поздравляю тебя!
Желаю интересных дел, больших достижений, хороших людей вокруг! А ещё - железного здоровья и счастья в личной жизни!

51
Отвечу немного в другом порядке.

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

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

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

Как это не работает?
Участники (1) - (5) тратят слишком много времени на то, чтобы прочитать и понять требуемое поведение артефакта (в т.ч. нужно множество итераций согласования и коррекции) и/или в результате получается не то, что написано в спецификации.

По моему, от аналитика зависит, работает или не работает.
И да, и нет. Можно предоставить спецификации - но нельзя заставить хорошо работать в соответствии с ними.

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

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

С третьей - есть ещё человеческий фактор: не все могут читать подробные спецификации в силу своего склада ума и темперамента (см., например, Rainwater "Herding Cats" и типологую Майерса-Бриггса), не у всех для этого есть мотивация.
----
Опять же, это всё - по моему мнению и на основании моей практики. Может статься, что Ваша команда действительно не испытывает проблем при чтении объёмных и сложных по форме спецификаций, и что программисты не рассматривают детальное описание поведения системы как вмешательство в творческую часть своей работы.

52
Думаю, такой "перекрёстный обстрел" может сильно понизить желание писать какие-либо статьи.

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

Мы в компании именно с помощью wiki это решаем. Хочешь поспорить - пиши/дописывай. Если же писать не хочешь или не можешь - значит, несогласие несущественно.

----

Моё личное мнение по поводу "исключений", и вообще по поводу сверхдетального описания всего и вся в UC: сложно, не работает. Не читают. Всё равно делают по-своему.

Если есть какой-то важный, но простой альтернативный поток - можно написать в UC. Ну а сколь-нибудь сложную логику я обычно описываю в activity, statechart, иногда даже sequence, прикреплённых к этому UC.

Если что-то опустил/упустил - при нормально налаженных рабочих и человеческих отношениях, программисты всегда переспросят "а как нужно-то"? А при отсутствии таких отношений даже сверхдетальный документ тоже слабо помогает. Разве что потом, при "разборе полётов", чтобы стало понятно, кого наказывать... Но ведь цель не наказать за то, что неправильно сделали, а сделать правильно.

53
Согласен, не учебник, а справочник :) .

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

 IMHO взялся писать (уже респект!), попал в ЧаВо - кому как не тебе поддерживать и дополнять :) ?

54
IMHO нет одного важнейшего случая - пользовательской истории, а-ля:

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

55
Это "реактивная" ветка. А есть ещё "проактивная". Например, сейчас мы не можем понять, как 10 лет назад обходились без мобильников. Или лет 5 назад никто не понимал, зачем обычной компании следить за рядовыми сотрудниками.

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

56
Между тем, где-то у японских менеджеров встречал высказывание, что повышение качества... снижает, а вовсе не повышает издержки на производство.

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

Так что уходить вперёд может быть выгодным. Тем более, что когда уходишь далеко вперёд, и при этом обеспечиваешь адекватную поддержку продаж и адекватное количество продукта/сервиса, становишься... монополистом.

57
По поводу оценки требований другими участниками команды.

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

С другой стороны, иногда требования нужны, чтобы "прикрывать пятую точку". В этом случае требования нужны тоже... весьма специфические. Тут уж МП или архитектор могут плохо оценивать простые и конкретные требования с хорошей тестируемостью.

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

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

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

58
А как обстоят дела с самым главным критерием - [финансовым] результатом?

Встречались ли Вы на практике с ситуациями, когда

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

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

59
<не уверен, что это сюда, но не нашёл раздела "сравнение методологий">

Вышел у меня на днях спор: кто такой системный архитектор?

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

Т.е. на входе у него новые требования, а на выходе новая архитектура и diff'ы между текущей архитектурой и новой архитектурой. А в самом лучшем случае - технические формулировки и очень примерные оценки трудоёмкости задач.

При этом архитектор может попросить уточнить требования, но сам их не диктует, аналитиками не управляет, с Заказчиками не беседует, roadmap единолично не задаёт.

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

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

Дамы и господа, как у кого разработка с точки зрения роли системного архитектора устроена? У кого к какому варианту склоняется, и что из этого получается?

60
<...>
есть еще TCR (Technical) к-е не всегда проходят через аналитиков
ну типа помнетяь SQL запрос (не меняя его логики) для оптимизации
ну или срочно что-нибудь с продакшн зафиксить
Конечно, можно сказать, что такова жизнь и никуда не деться, но весьма неприятно, когда в системе вдруг обнаруживается косой-кривой кусок функциональности "сбоку", который зачем-то нужно описать в требованиях пост-фактум, со всей кривизной, как реализовали. Потом, когда задают вопрос: "кто написал эти требования", приходится краснеть, хотя ты тут вроде бы и ни при чём.

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

IMHO лучше пользоваться требованиями с высоким приоритетом. Это, кстати, даёт возможность проверять: а на каком основании ведутся эти работы, а так ли высок приоритет, а кто за эти доработки платит и окупают ли они себя? Т.к. возможны варианты, когда менеджеры клиентов повышают прибыльность своих продаж за счёт неучтённой работы отделов разработки и внедрения.

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 »