Вы отнюдь не одиноки. Как консультант я работаю сейчас с ДИТ одного из банков. Там абсолютно такая же ситуация. До этого я работал с ВТБ ... Как правило это типовая проблема для многих организаций с собственным многочисленным подразделением разработчиков и множеством разрабатываемого ПО (но есть исключения!). И она имеет "2 стороны медали", как бизнесовую, так и собственно ИТ-шную:
1. Отсутствие заинтересованности со стороны бизнеса в эффективности ИТ. ИТ воспринимается как сервисное подразделение наравне с хозяйственными службами... и как затратная часть а не как инвестиционная.
2. Множество бизнес-заказчиков высокого ранга, которые сыпят доработки "как из рога изобилия", понимая, что деньги пойдут не из бюджетов их подразделений, а ИТ все это будет делать "за ту же зарплату". Как правило до 30% этих доработок можно было и вовсе не делать :-), если правильно организовать бизнес-процесс (но "мощности ИТ" уже были загружены этой работой).
3. Невысокая заинтересованность в конечном результате. Зачастую сложно найти ответственного за доработку/разработку в бизнес-подразделении. И даже когда ответственного назначают он тихо в курилке матерится что "эта программа никому не нужна". Соответственно возникают проблемы при сдаче-приемке такого софта.
4. Собственно со стороны ИТ нет четкого разделения между операционной и проектной деятельностью. Как правило управления проектами нет. В лучшем случае используется MS Project для "календарного планирования задач". Не ведется учет реальных трудозатрат.
5. Никто не контролирует архитектуру. Как системную так и программную (в пределе EA -- ну до этого у нас вообще не доросли :-)). Нет единых стандартов и правил ее описания. Толком никто не проводит анализ влияния изменений (что будет если тут изменим). Описания дизайна системы я вообще не разу не видел :-) ... в лучшем случае реверс-инжениринг сделают по коду, но это слабо проясняет ситуацию, т.к. трассировок на требования нет.
6. Нет единого репозитория требований к ПО. Как правило невозможно или затруднено получение полного перечня требований разного уровня к существующем релизам ПО.
7. Затруднена идентификация конфигураций, в т.ч. из-за отсутствия той же компонентной архитектуры. Слабое или недостаточное планирование релизов.
8. Традиционно системы создаются в архитектурном стиле "клиент-сервер" и представляют из себя в слабоструктурированные образования ("код в стиле спагетти"). Вынос бизнес-логики на уровень хранимых процедур зачастую не улучшает ситуацию, т.к. все равно остается проблематичным проводить анализ влияния.
9. QA ... ну это вообще отдельная тема. Отмечу что часто это даже не стоит во главе угла!!!
10. Нет Product Manager! Т.к. часто сложно идентифицировать собственно продукты :-).

Все это усугубляется "текучкой кадров" ... а knowlеdge management отсутствует как класс. Процедур распространения знаний о системах нет. Отсюда и вечная кадровая проблема, т.к. пытаются найти уже людей с опытом работы с подобной предметной областью - а их не так много как правило.

Есть ли решение? Да .. главное понять в чем проблема и иметь план действий. Если у вас будет неконтролируемый поток изменений и вы не приучите бизнес расставлять приоритеты (вместе с ним) то будет достаточно сложно вообще стабилизировать ситуацию. Кроме этого нужно показать что ИТ считает деньги ... это мощная переговорная позиция с бизнесом, когда у вас все подсчитано :-).
Но в любом случае нужно браться за улучшение процессов и повышение имиджа ИТ в организации. Улучшать процессы можно по-разному ... можно по-классике (часто начинают с конфигуправления и управления изменениями, а потом идут к требованиям и далее к архитектуре), можно брать за основу модель CMMI (при этом не обязательно сертифицироваться). ISO 9000 как показывает практика в отечественных условиях как-то выхолащивается ... и посему не слишком эффективна. Либо делать по-другому, например использовать Agile методологию Scrum тот же ... но это отдельная тема :-).
Если надумаете улучшать процессы - обращайтесь :-), обсудим, подумаем, предложим решения ... и реализуем :-).

andbary byur На редкость все правильно и верно написано, вот только я не очень люблю консультантов


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

andbary
1. Перечислена куча проблем, но не указано ни одно их (реальное) решение.
2. Попытка воспользоваться хоть чем то из перечисленного приведет к очередной Ж.


1. Вы думаете хоть один мало-мальски грамотный специалист на общее описание проблемы вам ответит конкретикой? Приведу пример -- описываю механику некий внешний эффект проявляющийся при движении автомобиля ... спрашиваю в чем может быть проблема? Он мне просто отвечает -- "да фиг его знает, может быть это ... или это ... или это ... вобщем привози, разберем, посмотрим ...". Он дал мне РЕАЛЬНОЕ решение? ... нет, т.к. "отвечает за базар" :-). Кроме этого, вы же не пишите софт который решает проблему заказчика, при этом не беря с него денег :-)?
2. Вы пробовали воспользоваться? Поделитесь вашим опытом :-), обсудим :-).

andbary
На своей горькой практике могу сказать, что обычно (читай всегда) когда так говорят, то делается следующее:
1. Показывается, что контора в полной заднице (обычно на основании уже имеющейся инфы).
2. Вводится пара фенечек (типа отчетов о проделанной работе или внедрения должности аналитика бизнес процессов или ISO или репозитория требований к ПО или итд).
2. Задница в реале меньше не становится, но всегда можно взять новые отчеты и показать как мы стали лучше работать и существенно яффяктивней реагировать на требования бизнеса.


Вы аппелируете к своему горькому опыту ... Интересно, с кем из процессных консультантов в области SE вы работали (какая компания). Я все эти 3 компании знаю и очень неплохо знаю людей которые в них работают ... и что они реально могут, а что нет ... "Имья сьестра, имья ...." (с) ....??? Поделитесь ... расскажите о конкретике, к которой вы сами как раз и призываете, о ВАШЕМ КОНКРЕТНОМ ОПЫТЕ.

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

1. Причины вашего скепсиса мне понятны. Могу сказать, что для того чтобы внедрять те же процессы разработки и управления требованиями нужно иметь не столько "грамотных проектировщиков", они то как раз требованиями не занимаются :-), а таки аналитиков, не так ли?
2. Эти самые аналитики должны действительно иметь определенный уровень знаний, не только в предметной области, но и так же в инженерии требований. Поднять их уровень знаний можно а)тренингами б)практическим использованием полученных на тренингах знаний. А это уже имеет собственное "заумное название" -- коучинг. Одна из ошибок заказчиков -- они думают что на тренингах (курсах) их ВСЕМУ НАУЧАТ, и потом ко мне же подходят люди прошедшие тренинги и говорят "мы ожидали что нас научат писать ТЗ и именно учитывая особенности нашей компании ..., а нам дали общие понятия". Спрашиваю "а кому вы сказали о ваших ожиданиях на этапе покупки этих тренингов?????" ... а в ответ что-то типа "ну мы думали что это и так понятно". И это говорят АНАЛИТИКИ, которые должны знать про раздел SRS "Assumptions and Dependences"!!!! Т.е. они сделали предположение, но об этом предположении НИКТО кроме них не знал. Повторюсь, что тренинги имеют другое назначение, нежели научить "как писать ТЗ именно на эту систему". Кроме этого наивно предполагать что за 2-3 дня можно "Научить писать ТЗ" Тренинги, коучинг и консалтинг -- это разные вещи. Не все консультанты это объясняют заказчику. Вывод -- умейте правильно пояснить ваши ожидания и имейте реалистичные ожидания ... и не думайте что за 500 USD вам решат проблему с "написанием ТЗ".
3. Еще один аспект. Приведу пример с теми же аналитиками. Знания должны даваться "just in time", когда они ДЕЙСТВИТЕЛЬНО нужны специалистам. Т.е. человек должен быть готов воспринимать эти знания. Оно конечно "наука не в лес а в голову", но тем не менее ... Если у человека нет желания учиться, получать знания, его и так все устраивает .. то он НЕ ВОСПРИМЕТ этих знаний.
4. Это же относиться и к внедрению процессов ... если у основной массы специалистов компании мнение, что "мы и так все знаем, все уже пробовали ... и юзкейсы писали -- это фигня полная -- "пляшущие человечики", и UML использовали", а начинаешь копать глубже и выясняешь, что у людей юзкейсы были "Вывод на экран результатов расчета", "Проверка пароля", "Печать чека банкоматом" ... а на UML диаграммах классов они хотели описать логику РАБОТЫ приложения :-). И таких случаев предостаточно ... Вы уверены что в вашем конкретном случае не было подобного?
4. Теперь давайте посмотрим насчет "очень и очень сложный и кропотливый процесс" и "человек реально его внедривший не будет с такой легкостью крутить понятиями" :-). Давайте сделаем так .. возьмем проект по разработке софта, возьмем меня, еще нескольких человек квалификации которых я доверяю ... и просто построим тот самый "репозиторий требований". Готов поспорить, что эта команда сделает это в разы быстрее вашей :-), причем не важно на каком инструментарии -- Rational, Telelogic или Borland ALM (я например владею этими инструментами). ПОЧЕМУ? Просто потому что а) у нас будет мотивация б) мы четко понимаем что это нам даст в проекте г) мы ОБЛАДАЕМ КВАЛИФИКАЦИЕЙ это делать ....
Когда вы у себя внедряли процессы -- все у вас были квалифицированы, мотивированы и понимали что это вам даст???? И я про то :-).

aag
3. Справедливости ради, характерная черта разработки ПО в банках - неоходимость в постоянных и неожиданных изменениях. Тут и ЦБ спасибо надо сказать, и др. ведомствам, да и внутри - динамика бизнеса...


Собственно об этом и речь, следует в этом случае ориентировать собственные процессы на УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ, и считая экономику этих изменений иметь адекватные ресурсы :-).

andbary
1. То есть все написанное вами в том топике идет как "просто треп" с целью привлечь внимание???
2. Я привел пример с репозитарием, для которого нужно планипрвание, если пожелаете могу еще кучу кейсов, вот только в жизни нас всегда ждут новые, еще не решенные задачи.


Да вобщем-то внимание меня уже мало интересует ... староват для этого :-). Вы бы про КОНКРЕТНЫЙ ваш опыт, в частности негативный рассказали. Касающийся именно процессов программной инженерии :-). Это в большей степени интересно, чем просто рефлексия на тему "какие консультанты нехорошие ребята" :-). Я вобщем-то свой опыт и ссылки даже на конкретный банк дал.

andbary
Слава Богу с процессными я сталкивался только на этом форуме, честно сказать, я не читал ваши ранние сообщения и не представлял, что Вы именно процессный!!!


А с какими сталкивались? ... ну я все прошу вас рассказать о КОНКРЕТНОМ опыте ... вы как-то не желаете этого делать. А говорите что консалтеры ребята неконкретные ... :-). Повторюсь, что именно этот конкретный опыт взаимодействия, по конкретной тематике наиболее интересен!!!!!

andbary
1. 2. 3. Да, аналитик является очень ключевой фигурой и я (на основание своего опыта) считаю, что это не тот навык которому можно обучить...


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

andbary
4. Я не готов обсуждать процесные методики!!! Мое личное мнение в этом больше вреда чем пользы. Из интересного обсуждения этой темы с которым я согласен - http://www.sql.ru/forum/actualthread.aspx?tid=300755&hl=iso#2737999 также мне импонируют рассуждения A_S_U в теме "управление" ( http://www.sql.ru/forum/actualthread.aspx?tid=345804&hl=a_s_u ).
5. Вы утверждаете, что выполните задачу, вот только из темы Пробы сил, следует, что пока "самолет не сбросит бомбы в реальной боевой обстановке" не поймешь, правильно ли процессные менеджеры выполнили свою задачу. Пока никто не доказал обратное, вам будет нелегко с проектами...

Мне уже не нужно доказывать теорему существования :-). Но если честно я не вполне понял что вы тут имеете ввиду ...

aag
Угум. Запланировали, запустили... и тут, бац - вышло новое положение ЦБ. Ищем свободные ресурсы - их нет. Значит, что - бросили то что напланировали, схватились за форму "УУУ". Сделали ее - бац! клиентщики в попытках угодить клиенту предложили ему новую услугу и ее нужно срочно реализовать. Только реализовали - бац! бац! И понеслось.... и все планы давно забыты.
А вот для того чтобы эти планы не менялись каждую неделю, нужно не BPM прежде всего внедрять. Нужна воля руководства. Причем не ИТ-руководства. А руководства, которое определяет, что лучше -возможно, терять деньги, не предложив вовремя новую услуги клиентам или сэкономить затраты на ИТ.


Насчет ЦБ и "вдруг" -- лукавите :-). ЦБ таки дает время :-). Другой вопрос когда ваши технологи об этом узнали :-) ... вот отсюда и "ЦБ-шный вдруг".
А то о чем вы говорите, это не столько воля руководства, сколько элементарный "портфолио менеджмент" ... он у вас в банке на уровне бизнесовых подразделений уже есть? Что и даже на уровне ИТ есть???? И неужели занимаетесь управлением рисками?

andbary
Кейсы:
Компания хранила в своей системе цены с НДС. Время от времени возникали проблемы с покупателями, которые требовали переделать им документы. Консультант ознакомившись с этой проблемой предложил ввести в системе округление до цены делящейся на ндс. Были потрачены серьезные ресурсы на переработку системы, и после того как ндс стал 18% округляться стало до 59 копеек вместо 6...
Самое правильное решение заключалось в исправление программной ошибки при печати налоговых документов (плавающей). Еще одно правильное решение заключалось в использовании курса делящегося на ндс (не для всех подходит).
Консультант не знаком с бухгалтерией и не мог обратиться ни к кому знающему...

С целью оптимизации и улучшения системы оплаты труда была предложена сбалансированная система показателей. Выбрано свыше 20 показателей, введены в учетную систему и...
Трудоемкость данной работы была существенна, я даже не говорю про правильность выбранных показателей, просто в процессе эксплуатации выяснилось, что они ко всему прочему могут меняться. В итоге люди перестали понимать за что они получают деньги и производительность снизилась.
Решение: Человек не способен (в большинстве своем) сосредоточиться больше чем на 3х показателях. Если это продавец, то прибыль, оборот, оплаты! Можно максимум проводить бонусные программы (разово) по отдельным показателям. Типа сейчас сезон новых клиентов и за них получают премию...
ЗЫ Прикольно, но я знаю 2х человек пославших стрим, так как почувствовали себя обиженными из-за того, что у новых клиентов лучше условия...

Надеюсь, я привел конкретные примеры???

Как говорят в Одессе "Где ваши примеры, а где процессы программной инженерии"? И эти самые консультанты в области программной инженерии? Я таки не понял ... возможно конечно это аллегория такая ... а, вроде понял тезис ... "все консалтеры ОДИНАКОВЫ" :-). А например что же специалисты этой компании, где KPI по мотивации вводились консалтерами, на этапе приемки работ не высказали свои опасения на счет этих самых 20 показателей? Просто потому, что наблюдать покуривая со стороны оно всегда проще, при этом ничего сам не делая :-). Вот в этом то все и дело.

andbary Я спросил, устраивают ли вас примеры? Вы начали "про Одессу", кончили про "курение"... Спрашиваю Вы всегда настолько неконкретны?
Наверно не все "консалтеры", но есть старая поговорка, что исключения, только подчеркивают правило!


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

andbary
А специалисты компании:
1. Тяжело возражать против вещей которые очень правильно звучат, а KPI звучит классно, как и переход количества в качество.
2. Статистика накапливается не сразу. Только ввод KPI занимает полгода, а "эффект" образуется спустя 1-2. Сразу определить где будет через такое время задница, весьма непросто, а без конкретных фактов пророчить, извините.
3. "Ничего не делая". Вы настоящий консалтер!!! Сходу обвинили во всех грехах курящих!!!
(Всегда знал, что куренье зло, но не представлял насколько )


Ха ... а с консалтерами вместе на пилотном проекте KPI не обкатали чтоли???? Тем более странно. Лично я в своей практике предлагаю заказчикам следующую обобщенную структуру работ:
1. Обследование (понимаю что к чему и даю рекомендации что и как улучшать будем)
2. Формируем программу работ пол улучшениям в терминах цель - мероприятие - риски. Тут все понятно ... есть цели которые мы хотим достичь, есть риски которые могут помешать, есть мероприятия которые должны способствовать достижению целей и устранять риски.
3. Реализуем ..
4. Пробуем НА ПРАКТИКЕ ... делаем выводы по результатам и вносим корректировки.

А вообще реально большинство клиентов пассивны .... думают что прийдут умные ребята и все разрулят, и будет счастье. Ан не всегда так получается -- чтобы получить от консалтеров реальное value -- нужно работать ВМЕСТЕ С НИМИ ... и вникать во все предложения. Только я в своей практике такое желание заказчика встречаю не часто ... обычно все зарываются в свои норки, становятся жутко занятыми -- им не досуг пообщаться, обсудить предлагаемые решения ... зато потом все становятся умными "как моя жена потом" (с) ... и говорят что консалтеры нифига не понимают в специфике организации/отрасли и т.п. .... :-). И зная такую особенность я стремлюсь максимально вовлечь в работу представителей заказчика ... и выстраиваю отношения так, чтобы заказчику совместная работа не казалась в тягость.