Обсуждение

А заложены ли в эти цифры потери на неэффективность самой системной инженерии? :-)

Мне думается что реальные потери гораздо выше промоделированных TRW. Т.е. у них модель работ ограниченная и измеряет только те потери которые видны по модели. На практике, все гораздо хуже. К примеру, у меня затраты на тестирование варьировались от 2х дней на билд до 15 минут. При этом разница между двумя днями и 15 минутами - качественная. Т.е. 2 дня тестирования - это 5 дней на цикл: типа +3 дня на исправление найденых багов и коммуникацию. Плюс задержки накапливаются: во время исправления внесены новые баги. Итого требуется несколько циклов. Суммарное время получается около месяца. А при 15 минутах на тестирование, все бы за полдня пофиксили при желании, ну за пару дней максимум при расслабленном подходе. И так везде. Другой пример, из-за особенностей структуры системы, настройка тестового окружения требует около дня. Так как для тестирования нужно часто конфигурить введены даже специальные должности и несколько человек занимаются только тем что конфигурят системы по запросам. Однако, 95% тестов лучше выполнять на более низком уровне, без всяких БД сокетов и прочего. Эффективность возрастает сразу на порядок, а цикл вненсения изменений можно сократить в несколько раз.

Я просто в детстве читал книгу Реинжиниринг Корпорации. Это одна из книжек которая сильно повлияла на мой подход к программированию, как не удивительно. Впрочем как утверждает Донской, разница между созданием программных систем и менеджерской деятельностью не так уж и велика, и то и другое суть разновидности информационных систем. Так вот, из этой книжки я усвоил правило что нужно стремиться не к 10% улучшениям, а к 100% или больше.

Кстати, Донской это от меня узнал -- про схожесть менеджерской деятельности и созданием программных систем (" Михаил Донской: Знаете, тут совсем недавно Анатолий Ливинчук мне сказал такую идею, что менеджеров надо учить программированию, потому что общий принцип организационного управления, на котором строится формирование человеческих коллективов, едины и для программ, и для человеческих формаций" -- http://www.svobodanews.ru/Transcript/2007/04/25/20070425140058520.html). Меня учили по-другому: маркетинговые исследования показали, что люди не отказываются от старого товара, ежели его характеристики менее чем на 30% хуже нового. Поэтому думать о менее чем 30% улучшений в целом просто нельзя, никто не купит. Ну, а другие книжки говорят, что целиться нужно в разы (в частном улучшении какого-то блока), чтобы во всей системе получить как раз эти 30%. Так что тут мы полностью совпадаем.

> Кстати, Донской это от меня узнал -- про схожесть менеджерской деятельности и созданием программных систем (" Михаил Донской: Знаете, тут совсем недавно Анатолий Ливинчук мне сказал такую идею, что менеджеров надо учить программированию, потому что общий принцип организационного управления, на котором строится формирование человеческих коллективов, едины и для программ, и для человеческих формаций" -- http://www.svobodanews.ru/Transcript/2007/04/25/20070425140058520.html). Прикольно :).

Поразмыслил еще немного на тему схожести программирования и менеджмента, и подумал, что учить надо обработке данных. Т.е. такой смежной области между программированием и математикой. Сжатие данных, фильтрация там, датамайнинг и т.д. и т.п. Сие занятие хорошо интуицию на учет издержек и критических участков/путей затачивает. К примеру, у меня сейчас есть несколько Гб данных, и их мой комп нексолько минут их только читает. Для интерактивной работы, это неудобно. Приходится данные компрессировать, чтобы быстрее читал, уже раз в 10 приудмал как сжать. Потом вот дошел до идеи что надо индексы построить, ибо мне все данные не нужны, а нужные события встречаются редко, т.е. их можно закешировать в виде индексов, и при обработке данных сразу прыгать в нужное место. А итог такой, что очень хорошо начинаешь понимать структуру данных и обнаруживаешь всякие неожиданные интересные взаимосвязи. Как писал тот же Донской, что они сделали в Каиссе возможность распечатывать внутренние ходы и переборы и потом внимательно их изучали. И тоже находили всякие нетривиальные вещи. Вот это, на мой взгляд, и есть основа подготовки архитектора ПО.

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