формирование стратегии развития компании на основе проектного подхода

[vespol]

Забавный прием придумал.
Проблема: перечень проектов очень длинный и, в основном, везде "красный Гантт". Типа как тут не опустить руки.
Решение: в онлайне формируется отчет "Кто крайний". По каждому проекту показан не Гантт, а одна-единственная операция, на которой застрял весь проект. С фамилией ответственного, естественно. Отчет еженедельно попадает кому положено для осуществления "мотивации"
Дополнение: сводные отчеты-примитивы. Количество задержанных проектов по подразделениям-виновникам. Тупо.
Дополнительное свойство: "крайнего" машина вычисляет по признаку "по операции отсутствует прогресс "завершена". Если человек сделал подтасовку и отчитался за невыполненную операцию, как за выполненную, крайним становится исполнитель следующей операции. Имеем конфликт, который не нужно разруливать: исполнители сами между собой разберутся.
Можно было бы сделать подтверждение прогресса предыдущей операции исполнителем следующей, но сложно в реализации.

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

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

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

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

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

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

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

[Равиль]

И зачем рекламировать это бред здесь?

Грубо и оскорбительно.
Никто ничего не реклаимрует.
Изложил точку зрения компании.
Они (точки зрения) бывают и иные, чем у Болдина.
Но всё, что не по Болдину - это всегда полный бред.
Кстати, Александр, не замечаете, что все вокруг (и компании, и специалисты), кроме Вас, конечно, ну полные недоумки и дебилы ...
Ничего личного.

[А.Б.]

Грубо и оскорбительно.
Никто ничего не реклаимрует.
Изложил точку зрения компании.
Они (точки зрения) бывают и иные, чем у Болдина.
Но всё, что не по Болдину - это всегда полный бред.
Кстати, Александр, не замечаете, что все вокруг (и компании, и специалисты), кроме Вас, конечно, ну полные недоумки и дебилы ...
Ничего личного.

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

Хотя, наверное "грубо и оскорбительно" это когда кому-то присваивают слова, которых он не произносил. Я бы даже сказал - это несколько неожиданно.

[Евгений_Кс]

ну полные недоумки и дебилы ...
Ничего личного.

Лично я планирую укусить Болдина 23 января 2009 года прямо в Москве

[А.Б.]

Лично я планирую укусить Болдина 23 января 2009 года прямо в Москве

Это надо планировать. Жду диаграмму Гантта

[Михаил_Шустер]

Где лохотрон то?

Значит все-таки ты. Мощно. Имей в виду, что со слов Стерлигова "на это потрачено много миллионов долларов"
Задумка, еще раз повторяю, гениальная. Опасение вызывает только фамилия. Распорядиться ею можно ох как... как с атомной бомбой. Это похлеще бомбы будет, экономической

[Михаил_Шустер]

...

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

[Михаил_Шустер]

Где лохотрон то?

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

[Сахават]

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

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

[А.Б.]

К кому из имеющих САПР можно обратиться чтобы добыть справочники комплектующих, используемых при конструировании? Мне нужен классификатор для системы поставок

www.ascon.ru

[Сахават]

Честно говоря не понял, что именно надо. Может просто ОКП устроит?

[alex9994]

К кому из имеющих САПР можно обратиться чтобы добыть справочники комплектующих, используемых при конструировании? Мне нужен классификатор для системы поставок

возможно это подойдет
http://aist.sibproject.ru/

[vespol]

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

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

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

Вопрос в другом, когда Вы пишете, что

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

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

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

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

[Михаил_Шустер]

Почему Вы так решили? Обычная организация, обычные планы и проекты, никакой запредельной невыполнимости

На первый взгляд. Мне, как Тортилле, уже от этого жить скучно. Чуть глубже занырни - все тот же старый знакомый.
Весь прикол в ограниченности ресурса "кормильцев". Проекты, как и прочее, делают не числом, а умением. В проекте работает не 40 человек, как кажется, а 1-2. В двух (трех, пяти) проектах не 80\120\200, а все те же 1-2.

Вы сами себе противоречите: если, как здесь написано, "обеспечена выполнимость плана", то почему тогда возникают случаи его невыполнения?

ЕСЛИ обеспечена. Тогда невыполнение-только дисциплина
Но она практически никогда не бывает обеспечена. Во всяком случае, я не встречал.

любые изменения - вызывают сопротивления, это факт общеизвестный

Я совсем о другом. Есть популярное заблуждение, что с помощью контроля можно что-то улучшить. Нельзя. При невыполнимом плане, контроль только увеличивает энтропию. Зачастую, из-за контроля, малозначимые вещи получают преимущество над значительными.

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

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

Техническая система не решает организационные вопросы

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

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

раньше исполнитель не делал эту операцию, а теперь вдруг взял и сделал. С чего бы это?

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

[Bend]

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

[vespol]

Вы сами себе противоречите: если, как здесь написано, "обеспечена выполнимость плана", то почему тогда возникают случаи его невыполнения?

ЕСЛИ обеспечена. Тогда невыполнение-только дисциплина
Но она практически никогда не бывает обеспечена. Во всяком случае, я не встречал.

Именно об этом и разговор, только я бы вдобавок отметил, что эта так называемая "дисциплина" не просто какая-то мелкая помеха, типа плохой-хороший человек, а целый материк разных проблем и вопросов

Я совсем о другом. Есть популярное заблуждение, что с помощью контроля можно что-то улучшить. Нельзя. При невыполнимом плане, контроль только увеличивает энтропию. Зачастую, из-за контроля, малозначимые вещи получают преимущество над значительными.

Согласен, хотя может не так категорично насчет бесполезности контроля. Как говорится, наши недостатки есть продолжение наших достоинств.

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

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

Но неужели Вы думаете, что в ряде случаев у того парня не найдется способов отмазаться, даже если другие знают, что он что-то там не выполнил? Да их просто море разливанное, это же просто классика жанра!

[hilton]

Спору нет, если проблема попадает в поле зрения у нее будет выше шанс на решение.

этого достаточно.

[hilton]

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

мне кажется, что Михаил сомневается в полезности контроля над бесполезными действиями. Я так понял. Может я и не правильно понял, не буду утверждать на 100%

[hilton]

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

стадия улучшения несколько раньше, чем контроль, имхо.

[Евгений_Кс]

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

Михаил, как, по каким критериям оценивается (следует оценивать) выполнимость плана?
Наличие ресурсов?
Реалистичные сроки?
Степень загруженности "стратегического ресурса", или, в Вашей терминологии, "кормильцев"?
Закладывемый уровень качества?
Детальность согласования ТЗ с заказчиком?

[Евгений_Кс]

Михаил, а идея-то Ваша интересная очень по поводу он-лайн отчета "кто крайний" со всеми дополнениями.

Насколько я понимаю, идея Шустера близка Арчибальду:

13.2. Концепция «Менеджер проекта как менеджер по взаимодействию»
Основа концепции управления интерфейсами заключается в том, что менеджер проекта планирует, вносит в календарный план и контролирует ключевые интерфейсные события проекта – одним словом, управляет ими, в то время как ответственные функциональные лидеры проекта управляют выполнением задач или работ в промежутках между этими событиями.
(Р. Арчибальд, Управление высокотехнологичными программами и проектами», с. 396)

Здесь Шустер и Арчибальд - сыновья процессного подхода.
В процессе главное не процесс, а вход и выход.
Даже главное не вход и выход, а согласование выхода со входом следующего процесса.
То есть люди должны сначала договориться:
-Я приму такой вход
-Хорошо, я обеспечу такой выход.

[Bend]

стадия улучшения несколько раньше, чем контроль, имхо.

Я думаю так: есть стадия, где (да, Евгений, согласен) есть вход, но нет выхода или нет входа, мы ее видим исходя из того он-лайн отчета, где "лампочка загорается". То есть мы контролируем выполнение проекта, и если появился сигнал ("лампочка"), мы улучшаем ту стадию.

[Михаил_Шустер]

-мне кажется, что Михаил сомневается в полезности контроля над бесполезными действиями. Я так понял. Может я и не правильно понял, не буду утверждать на 100%
-стадия улучшения несколько раньше, чем контроль

Я не сомневаюсь. Я считаю что такой контроль крайне вреден т.к. он усиливает приоритеты в достижении бесполезных целей и оттягивает ресурсы от полезных. Все как ужаленные бегают вокруг ерунды, в силу ее разнообразия (вариабельности) происходит сильный рост сложности. Входы и коммуникации забиты мусором и проходимы только под большим давлением. Перестают работать стандарты, какое-то время работают приказы, потом, по мере увеличения их числа (процентов на 30 в год) "выходят из строя" и они. Выходы происходят по случайному признаку, не все и не те, кпд процесса - паровозный.
Источником энтропии является некомпетентность. Каждый новый человек в аппарате управления добавляет работы 10-ти. Могу перечислить все источники, да наверное все их знают и так. Сейчас занимаюсь их "зачисткой", это море неблагодарной работы. Инструмент - http://www.iscra.ru/projects.html (презентация, извините, написана наспех), плюс Парус, Дело и база данных оборудования АЭС. Имхо, большего и не надо.

Так что, на все 100% Хотя, иное было бы удивительно

[Andruxa]

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

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

Источником энтропии является некомпетентность. Каждый новый человек в аппарате управления добавляет работы 10-ти. Могу перечислить все источники, да наверное все их знают и так.

При управлении невозможна полная компетентность, некоторый её уровень всегда имеет место. Отсюда "вырванное от элемента-производителя" управление - источник энтропии. Кстати встречал где-то доклад Арнольда, он говорил что системы управления с lambda > 2 неустойчивы к входным данным (lambda - число уровней управления) - появляются теневые подсистемы и пр. эффекты.
И тут вопрос возникает - почему же все равно существуют сложные системы управления? Неужели структура знаний и рынка так сложна, что её приходится так отражать...
Хотя может на практике идеализации модели Арнольда конечно не реализуются.

[hilton]

сам продукт должен быть предметом контроля, а не задачи проекта.
Я своим программистам всегда говорю, что дефекты "не твои или Васины, а в (разрабатываемой) системе!!!".

об этом и речь. Нет смысла разрабатывать дефективные системы и отвлекаться на контроль возможных дефектов в ней. Если сама система дефективная по определению.

[Andruxa]

об этом и речь. Нет смысла разрабатывать дефективные системы и отвлекаться на контроль возможных дефектов в ней. Если сама система дефективная по определению.

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

[Михаил_Шустер]

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

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

[Михаил_Шустер]

И всё же контроль необходим!

А разве я где говорил обратное?
Главное-не гоняться за призраками. Идеальная система не будет создана никогда и слава Богу. Любая система должна обслуживать здравый смысл, но если обслуживать нечего - какие претензии к пуговицам?

Проблема иерархий (в т.ч. при планировании и контроле) в том, что агрегировать можно только подобное. Такого "подобного" в системе очень немного, детали всегда не влазят в агрегат (на любом уровне) и остаются за бортом, пусть это даже 1 лямбда. А истина в них.
Вон, Сахават мечтает увидеть Гантта в линии. Получится-ведро ставлю

[А.Б.]

Выполнимость плана оценивается просто: "смогем" или "не смогем".
Заказчик, по хорошему, не хочет знать есть ли у нас для этого ресурсы и насколько у нас загружены "кормильцы". Ему нужен результат к определенному сроку, не сильно дороже чем планировалось и с приемлемым (для заказчика) уровнем качества. И нужен человек (один!) который ему - заказчику гарантирует этот результат.
...
А потом этот самый "гарант" транслирует это самое "смогем" в компанию и обеспечивает его выполнение...
Все просто.

[А.Б.]

Был рад увидеть здесь у коллег мнение: "Не следует разрабатывать дефективные системы и отвлекаться на контроль дефектов в них". Полностью согласен. Хотя, доказать эту простую мысль в компании невероятно трудно.

Немного ранее читал аналогичную мысль в ЖЖ одного известного консультанта. Правда консультант пришел к этому после нескольких проектов "реинжиниринга" - когда его команде нужно было восстановить документацию системы, которая давно работает но неизвестно как. Мысль простая: зачем сейчас (при наличии быстрых систем 3D-проектирования) восстанавливать техническую документацию например проекта "Ил-76".