Здравствуйте, mikkri, Вы писали:

IT>>Да это ради бога, только кодить он всё равно обязан

M>А вот что именно?
M>Предположим, фирма разрабатывает "типичную" корпоративную софтину:

M>Клиент: IE (Pure HTML), Delphi (более "продвинутая" версия GUI).
M>Сервер представления: IIS (ASP.NET, обертывающий бизнес логику в HTML и Web Services для клиентов).
M>Сервер бизнес-логики: C# код для бизнес-объектов (COM+ или еще что-нибудь компонентное, возможно, те же Web Services только более ориентированные на бизнес-функции).
M>БД: MS SQL Server и небольшое количество сохраненных процедур.

M>Так вот, вопрос такой: как ты себе представляешь участие архитектора в кодировании такой системы (помимо архитектуры, конечно; пожалуйста, подробно)?

Слишком мало данных. Интересно знать объём работ и сроки, сколько человек в команде, делается ли это на заказ или внутренный проект, первый подобный проект или применяются накатанные решения, имеются ли крупные выделенные модули. От этого зависят ответы на вопросы. Так же многое зависит от распределения ролей в коллективе.
Но, предположим, что это внутренняя работа, решено использовать новые технологии, от старых мало что можно использовать. Предположим также что период проектирования закончен и начался девелопмент по полной схеме.

1. Конечно же дизайн базы данных, который естественно будет корректироваться в процессе разработки. Тут стесняться не надо, всё должно быть в руках этого человека в течении всего цикла разработки. Естественно разработчики могут и должны вносить свои предложения, но всё должно согласовываться, никакой самодеятельности.
2. Далее в течении периода разработки совместно с DBA, если такой есть или самостоятельно необходимо погонять базу на предмет производительности, налить туда данных и посмотреть как ведут себя типовые запросы. Естественно, кое-что можно поручить и другим, но в этом процессе нельзя участвовать просто стоя за спиной.
3. Разработка фреймворка и ядра системы. Это по части наиболее опытного разработчика, которым у нас как раз и является архитектор. Пишем общие классы, общаемся в процессе с остальными девелоперами, выявляем проблемы и аккуратно их устраняем, находим новые решения и корректируем старые. Здесь вообще всегда можно найти чем занятся. Можно сделать комфортный наворот над ADO.NET и упростить работу сразу для всех в разы, можно узаконить и обязать всех использовать счётчики, что позволит немерянно облегчить себе жизнь при сопровождении. Естественно это нужно будет сначала попробовать, сделать соответсвующую поддержку, а затем внедрить среди разработчиков. Работы не много, но время потратить надо. Логи и обработка ошибок, да вообще типовой каркас приложения — это тоже работа архитектора.
4. Смотрим по сторонам, что можно ещё использовать на благо трудового коллектива. Читаем журналы, бродим по сети, пробуем, тестируем, подходящее применяем.
5. Само-собой code review, да и вообще весь процесс обучения и тренинга. При необходимости можно посидеть с программером и обсудить с ним алгоритм или показать ему личным примером что и как делать.
6. Во время внедрения системы стоим за спиной и наблюдаем за своими промахами и недоделками.
7. Так же, если конечно на это есть время, то можно взять на себя реализацию какой-нибудь небольшой задачи. Ничто не бьёт так больно и не заставляет задуматься о смысле жизни, как грабли положенные в темном углу самим собой.

Это всё конечно, когда дизайн системы уже закончен. Во время самого дизайна — это какая-нибудь рисовалка типа Розы или Visio, доска, маркер и пару собеседников, понимающих о чём речь. В архитектуру придуманную одним гением я не верю. Любую идею нужно детально обсудить и выслушать как можно большее число чужих мыслей и взглядов.
В период между митингами опять фреймворк, ядро и тесты, тесты, тесты. Т.е. кодинг, кодинг, кодинг. Ну, можно ещё RSDN почитать

Здравствуйте, Аноним, Вы писали:

А>Тогда архитектор совершенно не нужен для компаний в 10 чел занимающихся IT. Нужно 1-2 документалиста, 1-3 тестировщика, 3-6 программистов, 1 главный РМ, 1-2 внедренца — 7-14 людей, для повседневной организационной работы наделить координационными полномочиями еще пару человек, причем все равно будет ли это тестировщик, программер или внедренец, да даже документалист толковый вполне подойдет, главное чтобы умел с людьми общаться.

Трудно сказать нужен или не нужен. Это зависит от ситуации и от того что люди понимают под словом "архитектор".

А>А РМ занимается стратегическими-ключевыми вопросами — сбыт, архитектура, кадры — отдать власть хоть над одним из этих пунктов это роскошь которую не могут себе позволить и многие более крупные фирмы.

PM занимается реализацией требуемой функциональности в отведённые сроки. Причём тут кадры?

А>При проектировании учитываются мнение всех, а принимает решения все равно один. ИМХО в плане советов опытные программисты не хуже архитектора который кроме розы толком ничего в практике и не видел.

Ну вот опять. Ты путаешь слово архитектор с проектировщик, постановщик, бизнесс-аналист. Не может архитектор не зная программинга нарисовать работающую систему. НЕ МОЖЕТ. Любой сопливый студент через пол года поставит такого архитектора в позу и найдёт в его решениях кучу технических проблем. Поэтому опытный программист гораздо ближе к архитектору. Как правило они ими и становятся.

Здравствуйте, IT, Вы писали:

IT>То что у них с этим были проблемы и так понятно. Самое интересное что окончательное решение об использовании тех или иных технологий и одобрение дизайна системы должно исходить от PM, а не от архитектора. Именно PM ответственнен за успех любого безнадёжного предприятия. Архитектор — это его правая рука, возможно даже одно из полушарий мозга, но никак не орган принимающий производственные решения.

Не уверен что в конторах такого размера в России есть отдельный ПМ и отдельный архитектор.

Здравствуйте, IT, Вы писали:

IT>3. Разработка фреймворка и ядра системы. Это по части наиболее опытного разработчика, которым у нас как раз и является архитектор. Пишем общие классы, общаемся в процессе с остальными девелоперами, выявляем проблемы и аккуратно их устраняем, находим новые решения и корректируем старые. Здесь вообще всегда можно найти чем занятся. Можно сделать комфортный наворот над ADO.NET и упростить работу сразу для всех в разы, можно узаконить и обязать всех использовать счётчики, что позволит немерянно облегчить себе жизнь при сопровождении. Естественно это нужно будет сначала попробовать, сделать соответсвующую поддержку, а затем внедрить среди разработчиков. Работы не много, но время потратить надо. Логи и обработка ошибок, да вообще типовой каркас приложения — это тоже работа архитектора.
IT>4. Смотрим по сторонам, что можно ещё использовать на благо трудового коллектива. Читаем журналы, бродим по сети, пробуем, тестируем, подходящее применяем.

Очень похоже на то чем я сейчас занимаюсь, но я вроде как не архитектор


IT>В период между митингами опять фреймворк, ядро и тесты, тесты, тесты. Т.е. кодинг, кодинг, кодинг. Ну, можно ещё RSDN почитать

На самом деле на тяжелых вещах, вроде системной логики, на кодинг уходит удивительно малый процент времени.

Здравствуйте, AndrewVK, Вы писали:

AVK>Очень похоже на то чем я сейчас занимаюсь, но я вроде как не архитектор

Так вот и надо разобраться для начала что народ понимает под этим термином, а так же под его вариациями. Чем, например, отличается Software Architect от System Architect

IT>>В период между митингами опять фреймворк, ядро и тесты, тесты, тесты. Т.е. кодинг, кодинг, кодинг. Ну, можно ещё RSDN почитать

AVK>На самом деле на тяжелых вещах, вроде системной логики, на кодинг уходит удивительно малый процент времени.

Возможно. Но сколько потом времени уходит, если эта логика не работает

Здравствуйте, Аноним, Вы писали:

А>Устал я от споров бесконечных на уровне Артура Шопенгауэра, Канта и Гегеля.
А>Не могу дотянуться до небесного полета мысли.

А стоит иногда.

А>За последние четыре года мы сдали кучу проектов.
А>Начало.Электронные магазины — целых три.Быстрые деньги. Диплом.
А>Три сервера на перле+базы для них.
А>Портал на руби+база для него. С суппоротом
А>Мелкий офис на яве.
А>Еще на яве целую платформу построили за год.С суппоротом Было 4 девелопера, стало 10.
А>Нужен офис. 3х комнатной квартиры уже не хватает. 14 компьютеров — это слишком много.
А>Вышли на новый уровень. Взяли проект. Побольше. Подлиннее.
А>Деньги есть на налоги .
А>Пересели на буки — праграммим и на выходных и в гостях и в коммандировках.
А>Ура.
А>Нужны люди. Дизайнер и архитектор и тестировщик.

Ну, если на один проект, то, может быть, одного тестировщика и хватит...

А>Нашли. Взяли.

А>Работа.
А>Архитектора — знает, как потроить систему и знает, как решить проблему.
А>Архитектурщик может решить любую проблему и нарисовать любую ситему.
А>Но не все так просто — архитектурщик может решить только то , что описано без ошибок. И только на идеальных технологиях.
Из этого пассажа неясно, почему архитектор так плотно завязан на технологии...

A>Жава уже не то, а дотнет еще не это. У нас или много таблиц или слишком мало. Видители проблема в том, что мы взяли кое что из старых проектов. Да, нужен рефакторинг как минимум. А лучше с начала.

Да, попытка использовать старые наработки как "чёрный ящик" может привести к полному хаосу.

А>Денех нет ? Тогда он уходит.

Правильно делает, поскольку непосредственный результат его труда не виден сразу, следовательно его работа как минимум поначалу должна обеспечиваться результатами предыдущих разработок. В смысле — финансовыми

А>НУЖНО ЗАСАДИТЬ АРХИТЕКТУРЩИКА ЗА ПРОГРАММИНГ. СПУСТИТЬ его с небес на землю.

Мда. В контексте первоначального заявления о Шопенгауэре — логично. "По жизни" — чушь. Да, архитектор должен знать и уметь программинг, но ни о каком спуске с небес на землю не может идти и речи. Если конечно, не считать небесами списки перелопаченных технологий.

А>Или выгнать. Все равно это не архитектор.
А>Из за этого придурка мы теперь владеем всем, чем только можно владеть — ничем.



А>Наши люди освоили технологий немеряно а потом свалили на руководящие должности в другие конторы.

Они не увидели перспектив в своей "родной" фирме. Разумный ход. Вопрос — а где руководители были?

А>Мы только радовались, когда за месяц в Розе появилась наша система.
А>Оказалось, что он ее принес со старой работы и доработал.
А>Первая версия не понравилась заказчику. Сказали, что хорошо бы уменьшить время транзакции, увеличить пропускную способность и увеличить количество клиентов.

А вот это — ошибка и его и ваша. Требования по пропускным способностям, количеству клиентов и прочие, обусловленные некими объективными критериями (скорость, дальность, штуки, вес и т.п.) оцениваются в первую очередь.

А>Вот здесь все и открылось.

Здесь всё должно было закрыться.

А>Поределали. Установили ТТ — тесттрэкер. Раньше хватало экселя для багов.

Про эксель — плохо. Значит почти не занимались собственно организацией процесса.

А>Ну никак не вписывался наш проект в ту систему, котору спроектировал наш архитектурщик.

Супер! Фанфары в студию! Значит сделали что-то, непонятно что, которое само в себя не вписывается. Складывается ощущение, что вы ходили перед архитектором на цыпочках...

А>Произошел раскол. Часть людей заняли его позицию. Часть — нашу. Стариковскую.

Естественно.

А>Наша вина в том, что архитектурщик получил большую роль и огромное влияние.

Это — прямая ошибка обусловленная непониманием того, зачем нужен архитектор. И ты сам это непонимание демонстрируешь.

А>Он должен был работать вместе со всеми. Учавствовать в суппорте. Говорить с заказчиком. Писать ядро в конце концов. Время рассчитывать, учитывать.
А>И обязательно программить, программить и программить. Вернее — мы должны были заставить его это делать.

Эмоции твои понятны... Вот только прикол в том, что архитектор должен определять характер программинга и отвечать за структуры программы. В том числе, одна из задач архитектора — снижение количества программинга. Для этого и нужен некий взгляд "сверху". А заставить... боюсь, что это невозможно сделать "по ходу дела", если не оговорено изначально.

А>Конец проекту. Время прошло давно. Из багов не вылезли. Денег уже нет. Из первой четверки двое уже ушли.
А>Не верю, что можно чтото исправить.
А>Я тоже ухожу. Четвертый(он же первый) остался. Проект закрывает. Остается суппорт на четырех студентов на старые проекты.
А>Начнем снова вчетвером и сначала.
А>Квартиры не будет. Только удаленно и вчетвером.

А>Демократия скаталась в анархию.

А>0. Архитектуру разрабатывайте сами или дайте это лидер-программистам. Не одному человеку. Архитектура любая, выглядит красиво. Но не любая хорошо работает.

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

А>И заставляейте программить, программить + программить.

См. выше.

А>1. Посылайте крутых программеров подальше. Это или денег много или хрен заинтересуешь. А споров будет предостаточно, особенно, если он и в архитектуре чегото понимает. И вероятность, что свалит, предостаточна.

P=100%, особенно, если заставлять "программить". Как я понимаю, термином "крутой" ты обозначил человека с самостоятельным мышлением. Программинг, по-видимому, (восприятие у меня субъективное, но ты не определил сего слова точнее) подразумевает "лабание". Знаешь, не всякая пушка согласится палить по воробьям.

А>2. Берите исполнительных — это выяснить за месяц можно. Дайте мелкий проект в струю основного и он обучится. Дайте денег и время на сон и он будет с вами до конца.

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

А>3. Если много знает — значит врет. Если мало — значит не умеет учиться.
А>Проверить, насколько обучаем за месяц. Тестируйте людей программингом. Никаких поблажек даже знакомым и друзьям.

А вот с этим — согласен.

А>4. Организация должа продумывать и пробивать идеологию в своем коллективе.

Только тогда, когда она перерастёт влияние отдельных личностей.

А>Как только появилось начальство, сразу нашлись недовольные.

А что же тут удивительного? Это у начальников работа такая.

А>5. Появилась текучка — ищите причину, устраняйте.
А>Причины: ЗП,условия работы(расписание), интерес к работы, конфликты и тд.

Угу,

А>6. Пресекайте споры. Все обсуждения должны четко контролироваться кемто. Обязательно разрешать конфликты авторитетно, ен оставлять на самотек.

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

А>7. Дисциплина. Не зря распространились существа с центральной нервной системой.
А>Такая же ЦНС должны быть и в коллективе. Самодержавие и ничего больше. Никаких поблажек никому. Нахрен Линукс — это амебы, инфузории, черви. Их миллиарды. Виндоуз — млекопитающие с ЦНС. Все государства, имеющие в прошлом жесткую дициплину и агрессивную политику видны с пяти метров на карте мира.

Парадокс в том, что это совсем не обеспечивает выходного качества продукта. Можно окружить себя "исполнительными", "верными" и милыми (без кавычек) людьми. Но гарантии качественного результат в большом проекте это тебе никогда не даст. Не тот конец, извини за резкость. В армии много солдат, но есть и генштаб. На заводе туча рабочих, но есть и КБ. В организме есть ЦНС, но есть ещё и МОЗГ, а именно его наличие ты косвенно отрицаешь.

А>8. Берите проекты большие малые и средние. Обязательно с суппортом.
А>Малые — быстрые деньги — обучение.
А>Средние — чтоб не издохнуть, как мы.
А>Суппорт — буржуи онанируют на суппорт.
А>Большие — завоевание рынка.

В общем — без моих возражений. Но причём тут архитектор и его качества?

А>9. Считайте срочки в трудовой книжке. Чем больше, тем его не брать.

Очень спорно, ИМХО. Архитектор вполне может выполнять проект за проектом в разных конторах. Впрочем, как и "обычный" программист.

А>Аз есмь альфа и омега программерской конторы.

Конторы — может быть, организации... никогда.

ИМХО, собственно.

Рекомендую почитать статью Joel Spolsky Don't Let Architecture Astronauts Scare You.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Аноним, Вы писали:

IT>Трудно сказать нужен или не нужен. Это зависит от ситуации и от того что люди понимают под словом "архитектор".

согласен.


IT>PM занимается реализацией требуемой функциональности в отведённые сроки. Причём тут кадры?

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

IT>Ну вот опять. Ты путаешь слово архитектор с проектировщик, постановщик, бизнесс-аналист. Не может архитектор не зная программинга нарисовать работающую систему. НЕ МОЖЕТ. Любой сопливый студент через пол года поставит такого архитектора в позу и найдёт в его решениях кучу технических проблем. Поэтому опытный программист гораздо ближе к архитектору. Как правило они ими и становятся.

согласен.

Технологический подход к проблемам власти на предприятиях

Данилова Елена Николаевна

Старший менеджер компании "ПАКК"
Руководитель группы кадрового консультирования



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


Технологический подход

В основе любого производственного процесса лежит повторяющаяся жесткая последовательность действий, направленная на достижение заданного результата.

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

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

Такой принципиальный подход мы называем технологией, лежащей в основе производственного процесса.

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

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


Элементы технологии

Для стабильной власти необходимо наличие всех элементов системы:

Идеологи – первые и вторые лица организации, задающие нормы и правила для своей организации. Обладают правом менять эти правила. В политике идеологи формулируют свою позицию по отношению к внешней среде – обществу. На предприятии значение внешней среды вторично.

Команда единомышленников – небольшая группа лиц, разделяющих позицию идеологов. Идеологи «обкатывают» на них свои идеи, то есть команда – это полигон для того, кто определяет идеологию. На производстве единомышленник параллельно является функционером.

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

Функционеры – те, кто отвечают за функционирование механизмов, транслирующих идеологию на электорат.

Электорат – те, кто понимают и поддерживают идеологию, ценности, правила и нормы. Коллектив предприятия может не быть электоратом – он может принимать все, что идет сверху, исполнять все распоряжения, но в критических ситуациях (реорганизация, смена руководства и т.п.) не происходит воспроизводитства системы (то есть нарушаентся преемственность).

Резерв руководителей — это оснащенная управленческими навыками часть активного электората.

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

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

Для того, чтобы сформулировать принцип попробуем ответить на вопрос, что обеспечивает сохранение идеологии? Во-первых, наличие всех элементов системы, во-вторых, построение механизмов, которые транслируют идеологию на объект воздействия — электорат.

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


Принцип

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

Резерв единомышленников можно назвать «пятым элементом» технологии власти.

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

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

Отсутствие команды единомышленников

В этом случае существуют два варианта развития событий.

Первый вариант. Руководитель становится «свадебным генералом». Как правило, в управлении организации на верхнем уровне формируется пара: генеральный директор работает во внешней среде, первый заместитель контролирует ситуацию внутри.

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

Второй вариант. Нет единомышленников, и руководитель это видит и понимает.

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

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

Третий вариант. Внутри организации возникает лидер (или лиделы) транслирующий другую альтернативную идеологию. Это приводит к возникновению группировок и борьбе за власть. Это самая неприятная для эффективности предприятия ситуации, т.к. возникает среда интриг, борьбы за сферы влияния и ресурсы. Ее крайнее выражение «не мне, так и не кому» – в пределе развитие ситуации может привести к распаду организации или уничтожению бизнеса.

Если есть идеология, единомышленники – но нет функционеров? Тогда не формируется электорат – и управленческая верхушка существует в вакууме, рискуя уступить власть случайным хищникам.

Если функционер — сильный профессионал, управленец с собственной, другой идеологией – тогда идеолог-руководитель вынужден держать его только на позиции исполнителя, ограничивая потолок принятия решений. – К вопросу о разделе сфер влияния…

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

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

Пример – структуры органов власти, бывшие госучреждения и т.п.: «чиновничьи игры» подразумевают жесткую конкуренцию и борьбу за власть, и тогда для рядового персонала альтернатива – риск «быть съеденным» наверху или дойти до своего потолка и там остаться до пенсии».

Электорат как бы есть, имеется и управленческий резерв – «номенклатура» — но это совсем не тот резерв, на который хотел бы рассчитывать идеолог, пришедший в госсистему из бизнеса.

Для промышленных предприятий – это проблема отсутствия единомышленников на уровне менеджеров среднего звена, собственно тех, кто сможет в дальнейшем сможет войти в команду руководителя или заменить ее.

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

По моим наблюдения одной из самой болезненной тем для руководителей является: «А кому я оставлю все, что я построил? Кто придет на смену мне и моей команде, не разрушат ли то, что строилось годами?

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

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

Поэтому, когда мы говорим, что происходит, когда нет электората: нет в первую очередь преемников, которые смогут продолжить то, что начато.

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

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

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

Важен становиться не реальный результат, а то, как внешне выглядит твоя деятельность.

Взято с http://www.pacc.ru/

Здравствуйте, IT, Вы писали:

AVK>На самом деле на тяжелых вещах, вроде системной логики, на кодинг уходит удивительно малый процент времени.

IT>Возможно. Но сколько потом времени уходит, если эта логика не работает

Но ее работоспособность не очень то зависит от кодинга, куда больше от архитектуры.

Здравствуйте, AndrewVK, Вы писали:

АVK>Я думаю все таки помогут, многие вещи одинаковы как для мелких так и для крупных контор.
ну, business@speed of thought — не совсем то, что нужно.
Это книга в основном о том, чего руководители не-IT сектора должны и могут ожидать от IT-технологий. Чтобы не выдавать установку Excel за автоматизацию бизнеса.
Остальные пока не читал

Здравствуйте, Аноним, Вы писали:


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

Энтузиазм связаный с Rational Rose сильно поуменьшился когда стало понятно что неправильные картинки приводят к написанию неправильных программ ? Помоему вся проблема в том что народ забыл что такое архитектура, архитектура это НЕ рисование в розе. Я сейчас очень серьезно слежу за архитектурой не рисуя никаких UML диаграм.

Есть вполне конкретные цели архитектуры: это сделать проект легко сопровождаемым и расширяемым. Соотвтственно человек который отвесает за архитектуру проекта отвечает и за выбор технологий и за кодирование и за связи между компонентами. Данный человек не может не быть программистом, а заниматься "чистой архитектурой". Данный человек должен заниматься кодированием. Он принимает архитектурные решения и он должен самостоятельно проверять что они работоспособны/удобны и тп.

Вы знаете что такое бюрократия? Это когда административная машина созданная для реализации чего то, перестает делать это чего то, и ее единственной целью становится ее собственные бюрократические процедуры. Здесь мы помоему наблюдаем ту самую "бюрократизацию" дизайна.

Вот хорошо изложеные (отрицательные) характеристики архитектуры.
Цель архитектуры это предотвратить загнивание дизайна, а не рисовать в Rose.

What goes wrong with software? The design of many software applications begins as
a vital image in the minds of its designers. At this stage it is clean, elegant, and compelling.
It has a simple beauty that makes the designers and implementers itch to see it
working. Some of these applications manage to maintain this purity of design through
the initial development and into the first release.
But then something begins to happen. The software starts to rot. At first it isn’t so
bad. An ugly wart here, a clumsy hack there, but the beauty of the design still shows
through. Yet, over time as the rotting continues, the ugly festering sores and boils
accumulate until they dominate the design of the application. The program becomes a
festering mass of code that the developers find increasingly hard to maintain. Eventu-
ally the sheer effort required to make even the simplest of changes to the application
becomes so high that the engineers and front line managers cry for a redesign project.
Such redesigns rarely succeed. Though the designers start out with good intentions,
they find that they are shooting at a moving target. The old system continues to
evolve and change, and the new design must keep up. The warts and ulcers accumulate
in the new design before it ever makes it to its first release. On that fateful day,
usually much later than planned, the morass of problems in the new design may be so
bad that the designers are already crying for another redesign.

Symptoms of Rotting Design

There are four primary symptoms that tell us that our designs are rotting. They are not
orthogonal, but are related to each other in ways that will become obvious. they are:
rigidity, fragility, immobility, and viscosity.

Rigidity.
Rigidity is the tendency for software to be difficult to change, even in
simple ways. Every change causes a cascade of subsequent changes in dependent
modules. What begins as a simple two day change to one module grows into a multiweek
marathon of change in module after module as the engineers chase the thread of
the change through the application.
When software behaves this way, managers fear to allow engineers to fix non-critical
problems. This reluctance derives from the fact that they don’t know, with any reliability,
when the engineers will be finished. If the managers turn the engineers loose
on such problems, they may disappear for long periods of time. The software design
begins to take on some characteristics of a roach motel -- engineers check in, but they
don’t check out.
When the manager’s fears become so acute that they refuse to allow changes to software,
official rigidity sets in. Thus, what starts as a design deficiency, winds up being
adverse management policy.

Fragility.
Closely related to rigidity is fragility. Fragility is the tendency of the
software to break in many places every time it is changed. Often the breakage occurs
in areas that have no conceptual relationship with the area that was changed. Such
errors fill the hearts of managers with foreboding. Every time they authorize a fix,
they fear that the software will break in some unexpected way.
As the fragility becomes worse, the probability of breakage increases with time,
asymptotically approaching 1. Such software is impossible to maintain. Every fix
makes it worse, introducing more problems than are solved.
Such software causes managers and customers to suspect that the developers have lost
control of their software. Distrust reigns, and credibility is lost.

Immobility.
Immobility is the inability to reuse software from other projects or
from parts of the same project. It often happens that one engineer will discover that he
needs a module that is similar to one that another engineer wrote. However, it also
often happens that the module in question has too much baggage that it depends upon.
After much work, the engineers discover that the work and risk required to separate
the desirable parts of the software from the undesirable parts are too great to tolerate.
And so the software is simply rewritten instead of reused.

Viscosity.
Viscosity comes in two forms: viscosity of the design, and viscosity of
the environment. When faced with a change, engineers usually find more than one
way to make the change. Some of the ways preserve the design, others do not (i.e.
they are hacks.) When the design preserving methods are harder to employ than the
hacks, then the viscosity of the design is high. It is easy to do the wrong thing, but
hard to do the right thing.

Viscosity of environment comes about when the development environment is slow
and inefficient. For example, if compile times are very long, engineers will be
tempted to make changes that don’t force large recompiles, even though those
changes are not optiimal from a design point of view. If the source code control system
requires hours to check in just a few files, then engineers will be tempted to make
changes that require as few check-ins as possible, regardless of whether the design is
preserved.

These four symptoms are the tell-tale signs of poor architecture. Any application that
exhibits them is suffering from a design that is rotting from the inside out. But what
causes that rot to take place?

....

(c) Robert C. Martin

Дак вот предотвращение Rot of design это задача архитектора, а ее нельзя выполнить не замочив ноздри в кодировании.