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

×


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

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


Сообщения - Леонид

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 »
181
Цитата: kolodinivan
товаросопроводительные документы разве не на управления, если это вход во что они должны преобразовываться?

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

Как Вы думаете будет ли управлять принятие книг договор?

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

182
А тут вроде как можно сразу после этого кнопочку нажать и получить готовый документ, с которым можно сразу выходить с запросом на финансирование.

Милый способ манипулирования. На среднеглупом спонсоре (или которому просто пофиг) может и сработать. Ты кнопку жмак, компьютер бюджет - дзынь! И сразу видно, что у нас все по-честному, без обмана.

Предложеннная методика еще хороша тем, что легко позволяет сделать трассировку от стоимости в ТЭО  к фактической стоимости проекта

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

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

Вот! Вот это по-нашему! Только зачем при этом нужен какой-то расчет? Можно же играть сразу в бюджет: трудозатрат поменьше, профит побольше, результат быстрее и не нужно слушать капризы программиста (а то и целой команды) системы расчета.

183
Клованы.

184
Доброго дня, коллеги!
Кто-нибудь может подсказать, в чём принципиальное отличие этапов "ввод в опытную эксплуатацию асу" и "ввод в промышленную эксплуатацию асу" ?

Сначала вопрос: формулировки в кавычка - они откуда взяты? Это может быть важно.

Если же опираться на действующий 34-й ГОСТ, то принципиальное различие в том, что опытная эксплуатация (и "ввод" в нее) является одним из видов испытаний системы, а промышленная - уже ее полномасштабная, рабочая эксплуатация.

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

А если серьезнее, в данном случае нужен не flow (которого по сути нет), а некий регламент наделения полномочиями. Кому можно, что можно, где можно, в течение какого времени можно. А также, кто вносит изменения и кто контролирует. Под "кто" могут пониматься как роли в системе, так и должности в организации.

Если очень нужно описать именно процесс наделения полномочиями - ну так его и опишите. Мол, в начале не было ничего. И пришел админ, и сказал он "да будет пользователь". Увидел админ, что пользователь гол и одинок. И выдал он ему права, и включил его в группы. И увидел дело рук админа офицер СБ, и изрёк "это хорошо".

186
Здравствуйте!
Возникла потребность написать техническое задание на создание отчёта с графиками по ГОСТ 34.*
Задание прям вот совсем творческое получается, может быть есть пример такой работы для ознакомления и использования как основы?
Что из ГОСТ 34 взять за основу для ТЗ, подскажите кто знает.
Спасибо!

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

Если первое, то ГОСТ 34 вполне можно притянуть за уши. Если второе - то тоже можно, но это занятие из разряда "забей гвоздь отверткой".

В 1-м разделе пишем, как называется наш отчет, кто его разрабатывает и для кого.
Во 2-м разделе пишем, нафига этот отчет вообще нужен.
В 3-м - в каких условиях он будет формироваться. Какие данные для этого отчета у кого находятся, кто кому и когда их предоставляет.
В 4-м - конкретно расписываем, как должен выглядеть отчет и как считаться. Причем, если расчеты посложнее, чем "итого", их можно поместить в раздел "математическое обеспечение".

На все многообразие ГОСТа вроде "требований к мобильности" и "требований безопасности" кладем болт и не включаем в наше ТЗ на основании п.2.2 того же ГОСТ 34.602. Но делаем это осознанно: например, если для расчета показателей от сотрудника потребуется знание тервера, то указываем это в требованиях к персоналу.

В 5-м разделе пишем этапы разработки отчета: что, когда будет сделано и чем подтверждено.

В 6-м указываете, как будете сдавать отчет заказчику. На каких носителях, каким документом зафиксируете и т.п.

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

В 8-м - например, требование по разработке методички для отчета.

Ну и т.п., там немного осталось.

187
Ваш случай регулирует ГОСТ 2.105, обязательное применение которого при разработке ТЗ регламентируется п.3.2 ГОСТ 34.602.

Вообще, деление на тома - исторически сложившаяся практика, которая позволяла дробить килограммы бумажной документации на приемлемых размеров книжки (500 листов). Т.е. было одно ТЗ на 2000 листов + 400 листов приложений - получалось 5 томов, в последнем из которых шли приложения. Это если их включали в текст ТЗ, что делать необязательно (п.4.3.4 ГОСТ 2.105 "Приложение оформляют как продолжение данного документа на последующих его листах или выпускают в виде самостоятельного документа").
Если приложения включают в документ, то п.4.1.13 ГОСТ 2.105 велит: "Нумерация страниц документа и приложений, входящих в состав этого документа, должна быть сквозная."

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

А вообще, если есть вероятность того, что ТЗ будут драть по формальному признаку, я бы не фантазировал и сделал ровно так, как велит Стандарт.

188
Начать рекомендую...

Благодарю. Любопытно будет взглянуть.

189
Вторая теорема Деминга: «Больше всего вреда приносит тот, кто работает изо всех сил».
На русском есть похожая поговорка: "Опаснее всего дурак с мотивацией".

Только "с инициативой", а не с мотивацией. А зачем нам дураки?

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

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

Я видел такие разработки (этот поток организует по-своему) сделанные людьми, у которых было много мотивации и мало квалификации.
В газенваген.

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

Это работает для вырожденного производственного потока из одного рабочего центра и то не всегда. Организация как система так не работает. Смотри "Критическая сеть" Голдратта.

Надо бы. Давно откладываю на почитать.

> Например, на кассирах супермаркетов
Я работал к крупной (оборот более миллиарда долларов) розничной сети. Мне рассказывали истории про попытки введения KPI на продавцах в супермаркетах. Эти истории можно счесть весьма забавными, если у вас специфическое чувство юмора. Надо ли говорить что все эти KPI были быстро отменены?

Расскажешь подробнее? Любопытно.

Я на заре своей трудовой деятельности внедрял и в течение пары лет эксплуатировал BSC в милицейской структуре. BSC устанавливалась поверх "палочной" системы, была рассчитана не на персоналии, а на структурные подразделения и в целом "производственному процессу" никак не мешала. Ну, получали 2-3 отстающих свой пистон ежемесячно на общих совещаниях. Ну так они и так его получали, за куда большие косяки. Зато 2-3 передовика получали почет, поощрения с занесением и плюшки в виде  призов вроде телевизоров, видеомагнитофонов и прочей мелочи. Призы обратно не личные, а на подразделение. Ставились в дежурках, комнатах отдыха личного состава.
Отдельные командиры вдохновились и активно участвовали не только в подтягивании нужных показателей, но и в развитии самой BSC. В целом, считаю тот опыт довольно удачным.

190
Но черт даже с ней, с мотивацией.

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

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

Так вот он какой - бизнес-Грааль! :)

KPI - самый надежный из всех известных мне способов убить производственный поток.
В нетворческих областях "совсем не складывается".

Почему? Чисто теоретически, КПИ, как естественное развитие идей Тейлора, должны неплохо работать в хорошо нормируемой и детерминированной обстановке. Например, на кассирах супермаркетов или рядовых макдональдсов. Там, где понятно, из чего складывается производительность, каковы возможности среднего человека, широко применяется внешнее мотивирование и прочая, и прочая. Достоверной информации у меня нет, но то что слышал и видел, такую точку зрения не опровергает.
Но стоит только чуть выйти из зоны предсказуемости, или начать иметь дело с областями, где производительность человека при прочих равных скачет в диапазоне не десятков процентов, а на сотен и тысяч - всё, тейлорианство не тянет. Тянет подход "холодная голова, чистые руки и горячее сердце".

191
Леонид, спасибо! Вы чудо как мотивируете)

Рад стараться! :)

192
Не морочить голову - не вариант. Даешь KPI!)

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

Но Вы пробуйте, вдруг получится.

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

Зачем, если этот человек видит не только результат, но и весь путь к нему? И может на лету править тот или иной момент? Кстати, вот эти вот "последовательны", "недвусмысленны" очень зависят не только от разработчика, но и от потребителя. Особенно последнее.

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

Гм. Я вот, в роли аналитика, за последние 4 года не припомню разработанный мной лично или командой идеальных требований. За все стыдно, где больше, где меньше. Ибо, как сказал т.Сталин еще в 34 году, "Ведь инженер, организатор производства работает не так, как он хотел бы, а так, как ему прикажут, как велит интерес хозяина."

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

То есть, поправить ручками, если КПИ начинают показывать что-то не то? :)

Пусть такая оценка не точна, но она измерима и не субъективна - в этом ценность.

Чем неточная несубъективная оценка ценнее неточной субъективной? А вот стоит она неизмеримо дороже.
И, скажу по секрету, в творческих областях несубъективных оценок быть не может. Не верите - попробуйте самостоятельно разделить 100 условных рублей премии между программистом, аналитиком и тестировщиком проекта. Соразмерно вкладу. Да хоть между тремя программистами. Можно пользоваться любыми КэПэАйями, БээСЦами и прочими "системами". :)


Веса, приоритеты и параметры оценки можно редактировать по мере внедрения.

Да. Это очень понравится тем, кто уже успел соптимизировать свою работу под предыдущую версию КПИ.

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

O sancta simplicitas!
Впрочем, как говаривали в пору моего студенчества, "Если седой профессор говорит, что что-то возможно - это точно возможно. А если он говорит, что что-то невозможно - вполне может быть, что он заблуждается".

193
На основании чего оценить работу аналитиков

Корреляция есть не всегда. Хороший аналитик может запросто разрабатывать отвратительные требования по 9 из 10 разделам оценки. Зато в десятом разделе есть тот самый единственный критерий, который требуется задрать в данной конкретной ситуации. Гм... Зато наоборот гораздо реже. У плохих аналитиков хороших требований почти не получается.

194
Коли так, то для ответа нужен фундаментальный труд. Или сферические тезисы из оного. Навроде:

(про заказчика)
1. В течение какого времени согласуются требования? Отклонение от среднего по проектам?
2. Сколько проведено итераций их изменения, инициированных заказчиком?
3. Есть ли претензии к формулировкам у смежных (помимо функциональной) служб заказчика?
4. Какая часть требований на итоговых испытаниях вызывает вопрос заказчика "а нафига нам это надо?"
...

или (немного с другой стороны):
1. Соответствуют ли требования политической ситуации у заказчика? (не вызывают ли локальные очаги агрессии в давних терках между его подразделениями).
2. Соответствуют ли формулировки финансово-экономической политике заказчика? (т.е. если он проводит контракт по статье бюджета "доработка", никакой "разработки" в требованиях фигурироваьт не должно)
3. Соответствует ли общий объем требований ожиданиям заказчика (заплатил он 100500 млн рублей, и через 2 месяца работы получил 10 страниц требований).
4. и т.д.

И это мы еще не дошли до смысловой нагрузки требований.

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


195
Коллеги, как вы собираете обратную связь от ЗЛ по качеству требований? Опрос для всех? Интервью с каждым? Или только личное ощущение?

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

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

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 »